SV: force partition pruning

From: Niels Jespersen <NJN(at)dst(dot)dk>
To: David Rowley <dgrowleyml(at)gmail(dot)com>, Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: SV: force partition pruning
Date: 2021-05-12 02:46:30
Message-ID: 85050e6bba554ef5b4648b0a72c46baa@dst.dk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Fra: David Rowley <dgrowleyml(at)gmail(dot)com> Sendt: 12. maj 2021 02:34

>>
>> ok i think i just may be there is very less data , hence no index scan, no pruning.
>>
>> when i try to force seq_scan off,
>>
>
>Unfortunately, no run-time pruning occurred in the above plan.
>
>The fact that the above plan uses Append made that possible.
>
>I think, for now, the only sure way to get run-time pruning working for this case is to run two separate queries so that the 2nd one can
>perform plan-time pruning.

This is the conclusion I'm taking from this thread and will base my further work on. I was the one asking the original question. A table returning function is my work-hypothesis for now.

>
>
>I think if you try to make this work by trying to force the planner's hand, you'll just feel pain when the planner one day has a change of heart and decides to swap the join order on you.
>
>David
>
Thank you for the insights into the planner capabilities.

Regards Niels

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2021-05-12 03:42:03 Re: ERROR: no known snapshots
Previous Message David Rowley 2021-05-12 00:34:20 Re: force partition pruning