Original-Subject: Re: Strange behaviors with ranges
Original-From: Jean-Christophe BOGGIO <postgresql@thefreecat.org>
Message-ID: <6f6df414-625d-4c3e-8b9e-b772a376c149@thefreecat.org>
Date: Tue, 27 Aug 2024 21:54:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Strange behaviors with ranges
To: Paul Jungwirth <pj@illuminatedcomputing.com>,
  pgsql-general@lists.postgresql.org
References: <77691006-45f1-4ef9-bc1b-2eecd44f7d0d@thefreecat.org>
 <d784945a-88d4-413b-947e-1ed402982595@illuminatedcomputing.com>
Content-Language: en-US, fr
From: Jean-Christophe BOGGIO <postgresql@thefreecat.org>
In-Reply-To: <d784945a-88d4-413b-947e-1ed402982595@illuminatedcomputing.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/6f6df414-625d-4c3e-8b9e-b772a376c149%40thefreecat.org>
Precedence: bulk

Paul,

Le 27/08/2024 à 20:11, Paul Jungwirth a écrit :
> The issue is the order-of-operations used by the planner. If I put 
> EXPLAIN on your last query, I see:
>
>  Hash Join  (cost=16.64..109.90 rows=2410 width=64)
>    Hash Cond: (tmp_limitcontrats.idcontrat = paliers.idcontrat)
>    ->  Seq Scan on tmp_limitcontrats  (cost=0.00..35.50 rows=2550 
> width=4)
>    ->  Hash  (cost=14.27..14.27 rows=189 width=12)
>          ->  Seq Scan on paliers  (cost=0.00..14.27 rows=189 width=12)
>                Filter: (numrange(((qtep1 + 1))::numeric, 
> (qtep2)::numeric) <> '(,)'::numrange)
>
> So we are applying that filter to every row in paliers, not just the 
> one with idcontrat = 1003.

I understand, makes perfect sense. Thanks for the explanation. Have a 
nice day,