From: MichaelDBA <MichaelDBA@sqlexec.com>
To: Thomas Kellerer <spam_eater@gmx.net>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Strange runtime partition pruning behaviour with 11.4
Date: Sat, 3 Aug 2019 12:49:14 -0400
Message-ID: <eb26974b-c2b8-ce68-8aa0-5a300f308c02@sqlexec.com> (raw)
In-Reply-To: <9c55d578-bb70-d439-6450-abc291957ec3@gmx.net>
References: <29b2f4c6-987b-d364-2e1d-bbd479d06da2@gmx.net>
<cb89fa89-cef4-8510-2080-040712347b22@sqlexec.com>
<b9c05097-4c88-129a-545a-ab6997299b2b@a-kretschmer.de>
<9c55d578-bb70-d439-6450-abc291957ec3@gmx.net>
I too got the same plan (non runtime partition pruning plan) with or
without the statistics. So it looks like the workaround until this is
fixed is to re-arrange the query to do a subselect to force the runtime
partition pruning as Andreas suggested, which I tested and indeed does
work for me too!
Regards,
Michael Vitale
Thomas Kellerer wrote on 8/3/2019 10:06 AM:
>> it's posible to rewrite the query to:
>>
>>
>> test=# explain analyse select count(*) from foo_bar_baz as fbb where
>> foo_id = (select foo_id from foo where foo_name = 'eeny');
>>
>> I know, that's not a solution, but a workaround. :-(
>
> Yes, I discovered that as well.
>
> But I'm more confused (or concerned) by the fact that the (original)
> query works correctly *without* statistics.
>
> Thomas
>
>
>
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: MichaelDBA@sqlexec.com, spam_eater@gmx.net, pgsql-performance@lists.postgresql.org
Subject: Re: Strange runtime partition pruning behaviour with 11.4
In-Reply-To: <eb26974b-c2b8-ce68-8aa0-5a300f308c02@sqlexec.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox