Re: [PERFORM] SELECT slows down on sixth execution

2015-10-17 4:29 GMT+02:00 Jonathan Rogers : > On 10/14/2015 05:01 AM, Pavel Stehule wrote: > > Hi > > > > 2015-10-14 9:38 GMT+02:00 Jonathan Rogers > >: > > > > I have a very complex SELECT for which I use PREPARE and then > EXECUTE. > > The first five time

Re: [PERFORM] SELECT slows down on sixth execution

On 10/14/2015 05:01 AM, Pavel Stehule wrote: > Hi > > 2015-10-14 9:38 GMT+02:00 Jonathan Rogers >: > > I have a very complex SELECT for which I use PREPARE and then EXECUTE. > The first five times I run "explain (analyze, buffers) execute ..." in > psq

Re: [PERFORM] SELECT slows down on sixth execution

On 10/16/2015 08:37 AM, Albe Laurenz wrote: > Jonathan Rogers wrote: >>> Look at the EXPLAIN ANALYZE output for both the custom plan (one of the >>> first five executions) and the generic plan (the one used from the sixth >>> time on) and see if you can find and fix the cause for the misestimate. >

Re: [PERFORM] query partitioned table is very slow

Vladimir Yavoskiy writes: > I have about 900 partitioned tables with 67 millons rows. > And I found that my query takes too much time! That's about 100X partitions too many for that amount of rows. Partitions are a good thing in small doses, otherwise planning time will kill you.

[PERFORM] query partitioned table is very slow

I have about 900 partitioned tables with 67 millons rows. And I found that my query takes too much time! -- explain ( ANALYZE,VERBOSE,BUFFERS ) select report_id from cars."all" WHERE report_datetime = '2015-10-1

Re: [PERFORM] SELECT slows down on sixth execution

Jonathan Rogers wrote: >> Look at the EXPLAIN ANALYZE output for both the custom plan (one of the >> first five executions) and the generic plan (the one used from the sixth >> time on) and see if you can find and fix the cause for the misestimate. > > Yes, I have been looking at both plans and ca