Re: open/lseek overhead with many partitions (including with "faster partitioning pruning")

On 4 April 2018 at 12:31, Amit Langote wrote: > On 2018/04/04 9:27, David Rowley wrote: >> Yeah, this will no doubt be due to the fact that we still build >> RelOptInfos in the planner for all partitions, so we're still doing >> get_relation_info() and

Re: open/lseek overhead with many partitions (including with "faster partitioning pruning")

On 2018/04/04 9:27, David Rowley wrote: > On 4 April 2018 at 07:46, Justin Pryzby wrote: >> TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file >> backing every table being queried, even for those partitions eventually >> "excluded". > > Yeah, this

Re: open/lseek overhead with many partitions (including with "faster partitioning pruning")

Hi Justin. On 2018/04/04 4:46, Justin Pryzby wrote: > TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file > backing every table being queried, even for those partitions eventually > "excluded". That's expected. The faster pruning patch doesn't change the behavior with

Re: open/lseek overhead with many partitions (including with "faster partitioning pruning")

On 4 April 2018 at 07:46, Justin Pryzby wrote: > TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file > backing every table being queried, even for those partitions eventually > "excluded". Yeah, this will no doubt be due to the fact that we still build

open/lseek overhead with many partitions (including with "faster partitioning pruning")

TLDR: even with "faster pruning" patch, pg11dev open()+lseek() every file backing every table being queried, even for those partitions eventually "excluded". One of our customers (with the largest number of child tables, currently of relkind='r') takes a long time to plan query, and I wondered