From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | martin(dot)querleu(at)effisys(dot)fr |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Strange query planner behavior |
Date: | 2019-11-30 09:55:26 |
Message-ID: | CAFj8pRBYY9D0UW44=AKeBG8BJXq4NHA4WqAofLDQWAUFCfLQXA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi
so 30. 11. 2019 v 10:31 odesílatel EffiSYS / Martin Querleu <
martin(dot)querleu(at)effisys(dot)fr> napsal:
> Hello
>
> I have a strange problem with the query planner on Postgresql 11.5 on
> Debian stretch, the plan differs between the following 2 requests:
>
> - SELECT * FROM LIVRAISON WHERE ID_MASTER = 10 which uses a btree index
> on ID_MASTER (the table has 1M rows). Everything is normal
> - SELECT * FROM LIVRAISON WHERE ID_MASTER = (SELECT 10) which uses a seq
> scan and is 3000 times slower
>
> I don't understand how the planner cannot consider that a subselect with
> an = is equivalent to having = VALUE (the subselect either returning 1
> row or NULL)
>
> I don't have the same behavior on other column with indexes of the same
> table, maybe it's because 99% or the table has ID_MASTER = 0? I can
> understand that if the value returned by the subquery is 0 the seqscan
> could be faster (in our case it is still slower than index scan but only
> by 2 times), but if the subquery does not return 0 in no case the
> seqscan could be faster. The question is why is the subquery not
> calculated before choosing wether to use the index or not since it will
> return a single value?
>
> Thanks for your reply and sorry if the question is stupid
>
please try
1. run vacuum analyze on LIVRAISON
2. send result of EXPLAIN ANALYZE SELECT * FROM ... for both cases
here is a tool for sharing explains https://explain.depesz.com/
Regards
Pavel
>
> Best regards
> Martin Querleu
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-11-30 09:59:05 | Re: Strange query planner behavior |
Previous Message | Petr Fedorov | 2019-11-30 09:28:18 | Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |