| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)com>, Evgeny Gridasov <eugrid(at)fpm(dot)kubsu(dot)ru>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] EXPLAIN ANALYZE on 8.2 |
| Date: | 2006-12-15 14:56:57 |
| Message-ID: | 5822.1166194617@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Fri, Dec 15, 2006 at 12:20:46PM +0000, Simon Riggs wrote:
>> Maybe sampling every 10 rows will bring things down to an acceptable
>> level (after the first N). You tried less than 10 didn't you?
> Yeah, it reduced the number of calls as the count got larger. It broke
> somewhere, though I don't quite remember why.
The fundamental problem with it was the assumption that different
executions of a plan node will have the same timing. That's not true,
in fact not even approximately true. IIRC the patch did realize
that first-time-through is not a predictor for the rest, but some of
our plan nodes have enormous variance even after the first time.
I think the worst case is batched hash joins.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-12-15 15:17:20 | Re: invalid input syntax for type timestamp. |
| Previous Message | Peter Eisentraut | 2006-12-15 13:06:55 | Re: [PERFORM] EXPLAIN ANALYZE on 8.2 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron | 2006-12-15 15:04:58 | Re: New to PostgreSQL, performance considerations |
| Previous Message | Greg Smith | 2006-12-15 14:50:15 | Re: New to PostgreSQL, performance considerations |