Re: force partition pruning - Mailing list pgsql-general

From Vijaykumar Jain
Subject Re: force partition pruning
Date
Msg-id CAM+6J96bAMAmfiHY5xbwcfaAg3oFNehyspFHN5=Bz7LHpBCLig@mail.gmail.com
Whole thread Raw
In response to SV: force partition pruning  (Niels Jespersen <NJN@dst.dk>)
List pgsql-general
Fair enough.

Many thanks for taking time out to follow up and clear my misunderstanding.
I’ll not pollute the thread , since OP got what he wanted.
But I’ll have to spend more time trying to simulate it with data and reread what you want to say :).
But thanks again for clearing that up.


On Wed, 12 May 2021 at 8:16 AM Niels Jespersen <NJN@dst.dk> wrote:
Fra: David Rowley <dgrowleyml@gmail.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
--
Thanks,
Vijay
Mumbai, India

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: no known snapshots
Next
From: reg_pg_stefanz@perfexpert.ch
Date:
Subject: Re: ERROR: no known snapshots