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 <n...@dst.dk> wrote: > Fra: David Rowley <dgrowle...@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
