Re: partitioning performance tests after recent patches

2019-04-15 Thread Tom Lane
Amit Langote writes: > On 2019/04/15 4:19, Floris Van Nee wrote: >> 2) Is running non-inlined SQL functions with a generic plan even the best >> option all the time? Wouldn't it be better to adopt a similar approach to >> what plpgsql does, where it tries to test if using a generic plan is >> b

Re: partitioning performance tests after recent patches

2019-04-15 Thread David Rowley
On Mon, 15 Apr 2019 at 19:33, Floris Van Nee wrote: > Here's the output of explain/analyze for HEAD. At run-time, technically all > partitions could be pruned directly. However, one partition remains in the > output of explain/analyze because of other difficulties with removing all of > them, i

Re: partitioning performance tests after recent patches

2019-04-15 Thread Amit Langote
Hi, Thanks a lot for very exhaustive testing. David already replied to some points, but let me comment on a couple of points. Please be advised that these may not be the numbers (or scalability pattern of these numbers) you'll see when PG 12 is actually released, because we may end up changing s

Re: partitioning performance tests after recent patches

2019-04-15 Thread Floris Van Nee
David Rowley Sent: Monday, April 15, 2019 1:25 AM To: Floris Van Nee Cc: Pg Hackers Subject: Re: partitioning performance tests after recent patches [External] On Mon, 15 Apr 2019 at 07:19, Floris Van Nee wrote: > 3) What could be causing the big performance difference between case 7 > (sim

Re: partitioning performance tests after recent patches

2019-04-14 Thread David Rowley
On Mon, 15 Apr 2019 at 07:19, Floris Van Nee wrote: > 3) What could be causing the big performance difference between case 7 > (simple SELECT) and 8 (simple SELECT with ORDER BY LIMIT 1)? For 4096 > partitions, TPS of 7) is around 5, while adding the ORDER BY LIMIT 1 > makes TPS drop well bel