Re: speeding up planning with partitions - Mailing list pgsql-hackers

From Amit Langote
Subject Re: speeding up planning with partitions
Date
Msg-id d40ad7e3-10aa-6f89-9864-a2ed89b918b1@lab.ntt.co.jp
Whole thread Raw
In response to RE: speeding up planning with partitions  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: speeding up planning with partitions  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
Tsunakawa-san,

On 2019/02/08 10:50, Tsunakawa, Takayuki wrote:
> From: David Rowley [mailto:david.rowley@2ndquadrant.com]
>> It's good to see work being done to try and improve this, but I think
>> it's best to do it on another thread. I think there was some agreement
>> upthread about this not being Amit's patch's problem. Doing it here
>> will make keeping track of this more complex than it needs to be.
>> There's also Amit's issue of keeping his patch series up to date. The
>> CFbot is really useful to alert patch authors when that's required,
>> but having other patches posted to the same thread can cause the CFbot
>> to check the wrong patch.
> 
> OK, you're right.  I'll continue this on another thread.

Thank you.  I do appreciate that Imai-san has persistently tried to find
interesting problems to solve beyond the patches we're working on here.
Maybe I chose the the subject line of this thread poorly when I began
working on it.  It should perhaps have been something like "speeding up
planning of point-lookup queries with many partitions" or something like
that.  There are important use cases beyond point lookup even with
partitioned tables (or maybe more so with partitioned tables), but perhaps
unsurprisingly, the bottlenecks in those cases are not *just* in the planner.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: dsa_allocate() faliure
Next
From: Peter Geoghegan
Date:
Subject: Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)