| From: | MichaelDBA <MichaelDBA(at)sqlexec(dot)com> |
|---|---|
| To: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Strange runtime partition pruning behaviour with 11.4 |
| Date: | 2019-08-03 16:49:14 |
| Message-ID: | eb26974b-c2b8-ce68-8aa0-5a300f308c02@sqlexec.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
>
>
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2019-08-05 07:29:33 | Re: Strange runtime partition pruning behaviour with 11.4 |
| Previous Message | Tom Lane | 2019-08-03 16:05:53 | Re: Strange runtime partition pruning behaviour with 11.4 |