From: | Jean-Christophe BOGGIO <postgresql(at)thefreecat(dot)org> |
---|---|
To: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Strange behaviors with ranges |
Date: | 2024-08-27 19:54:24 |
Message-ID: | 6f6df414-625d-4c3e-8b9e-b772a376c149@thefreecat.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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,
From | Date | Subject | |
---|---|---|---|
Next Message | Stanislav Kozlovski | 2024-08-27 20:38:03 | tsvector limitations - why and how |
Previous Message | Adrian Klaver | 2024-08-27 18:27:42 | Re: Strange behaviors with ranges |