Subject: Re: Strange runtime partition pruning behaviour with 11.4
To: Thomas Kellerer <spam_eater@gmx.net>
Cc: pgsql-performance@lists.postgresql.org
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>
From: MichaelDBA <MichaelDBA@sqlexec.com>
Message-ID: <eb26974b-c2b8-ce68-8aa0-5a300f308c02@sqlexec.com>
Date: Sat, 3 Aug 2019 12:49:14 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <9c55d578-bb70-d439-6450-abc291957ec3@gmx.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

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