Re: Strange behaviors with ranges - Mailing list pgsql-general

From Jean-Christophe BOGGIO
Subject Re: Strange behaviors with ranges
Date
Msg-id 6f6df414-625d-4c3e-8b9e-b772a376c149@thefreecat.org
Whole thread Raw
In response to Re: Strange behaviors with ranges  (Paul Jungwirth <pj@illuminatedcomputing.com>)
List pgsql-general
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,





pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Strange behaviors with ranges
Next
From: Stanislav Kozlovski
Date:
Subject: tsvector limitations - why and how