Re: [PERFORM] Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time

2011-08-04 Thread Clem Dickey
On 08/03/2011 06:29 AM, Robert Haas wrote: b. the Merge Join cost estimator did a poor job with the data it was given: In function eqjoinsel_inner there are two cases (1) ANALYZE data is available for both sides of the join and (2) ANALYZE data is missing for one or both sides. Due to the GROUP

Re: [PERFORM] Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time

2011-08-03 Thread Robert Haas
On Fri, Jul 8, 2011 at 9:33 PM, Clem Dickey dicke...@us.ibm.com wrote: a. The Join cost estimators could have been given more information The functions which estimate JOIN selectivity (e.g. the chance that tuples will match in an equijoin, for instance) use data produced by ANALYZE. But the

[PERFORM] Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time

2011-07-10 Thread Clem Dickey
On 07/06/2011 05:59 PM, Clem Dickey wrote: On 07/05/2011 07:26 PM, Clem Dickey wrote: Column | Type | Modifiers +-+--- y | integer | not null x | integer | not null k | integer | not null j | integer | not null z | integer | not null Indexes: t_pkey PRIMARY KEY, btree

[PERFORM] Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time

2011-07-07 Thread Clem Dickey
On 07/05/2011 07:26 PM, Clem Dickey wrote: Updates after belatedly reading the slow queries guidelines: Version: PostgreSQL 8.4.8 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2), 64-bit The query has always been slow; the table for this test case is