| From: | Josh Berkus <josh(at)agliodbs(dot)com> | 
|---|---|
| To: | Kevin Brown <kevin(at)sysexperts(dot)com> | 
| Cc: | 'Postgresql Performance' <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: Joel's Performance Issues WAS : Opteron vs Xeon | 
| Date: | 2005-04-23 18:27:42 | 
| Message-ID: | 200504231127.42389.josh@agliodbs.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Jim, Kevin,
> > Hrm... I was about to suggest that for timing just the query (and not
> > output/data transfer time) using explain analyze, but then I remembered
> > that explain analyze can incur some non-trivial overhead with the timing
> > calls. Is there a way to run the query but have psql ignore the output?
> > If so, you could use \timing.
>
> Would timing "SELECT COUNT(*) FROM (query)" work?
Just \timing would work fine; PostgreSQL doesn't return anything until it has 
the whole result set.  That's why MSSQL vs. PostgreSQL timing comparisons are 
deceptive unless you're careful:  MSSQL returns the results on block at a 
time, and reports execution time as the time required to return the *first* 
block, as opposed to Postgres which reports the time required to return the 
whole dataset.
-- 
Josh Berkus
Aglio Database Solutions
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Plotkin | 2005-04-23 18:37:30 | Re: Disk filling, CPU filling, renegade inserts and deletes? | 
| Previous Message | Christopher Browne | 2005-04-23 18:27:12 | Re: Joel's Performance Issues WAS : Opteron vs Xeon |