From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org |
Subject: | Re: Tuning planner cost estimates |
Date: | 2005-05-20 23:06:51 |
Message-ID: | 4415.1116630411@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> Does this sound like a reasonable approach? Also, how important do
> people think it is to use explain analyze output instead of just doing
> SELECT count(*) FROM (query you actually want to test)? (The select
> count(*) wrapper is just a means to throw away the results since we
> don't really want to worry about data transfer times, etc). The testing
> I've done (http://stats.distributed.net/~decibel/base.log) shows explain
> analyze to be almost 5x slower than select count(*), so it seems a big
> gain if we can avoid that.
I'd go with the select count(*) --- I can't imagine that we will be
trying to model the behavior of anything so complex that we really need
explain analyze output. (On the other hand, recording explain output is
a good idea to make sure you are testing what you think you are testing.)
Actually, it might be worth using "select count(null)", which should
avoid the calls to int8inc. I think this doesn't matter so much in CVS
tip, but certainly in existing releases the palloc overhead involved is
noticeable.
BTW, 5x is an awful lot; I've not noticed overheads more than about 2x.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomaz Borstnar | 2005-05-21 07:42:00 | Re: Error when try installing pgbench ? |
Previous Message | Jim C. Nasby | 2005-05-20 22:49:17 | Re: Tuning planner cost estimates |