Re: Strange query planner behavior

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
>
>
>

In response to

Responses

Browse pgsql-bugs by date

  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