On Fri, 16 Nov 2018 at 12:06, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Oh, I just found the throw-away patch I wrote ages ago down the back > of the sofa. Here's a rebase. It somehow breaks initdb so you have > to initdb with unpatched. Unfortunately I couldn't seem to measure > any speed-up on a random EDB test lab Linux box using pgbench -S (not > "prepared"), but that test doesn't involve many tables, and also it's > an older kernel without KPTI mitigations. Attached in case anyone > else would like to try it.
Over on [1] there's some talk about how when using PREPAREd statements on a table with many partitions where some of the parameters help prune many of the partitions, that on the 6th, and only on the 6th execution of the statement that there's a huge spike in the query latency. This will be down to the fact that GetCachedPlan() builds a generic plan on the 6th execution and most likely discards it due to it appearing too expensive because of lack of any partition pruning. The custom plan's cost is likely much much cheaper, so the generic plan is planned but never used. This may be a good real-life candidate to test this patch with. I know from benchmarks I performed several months ago that the lseek() call to determine the relation size was a large part of the cost of planning with many partitions. [1] https://www.postgresql.org/message-id/flat/25C1C6B2E7BE044889E4FE8643A58BA963D89214%40G01JPEXMBKW03 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
