| From: | PFC <lists(at)peufeu(dot)com> |
|---|---|
| To: | "ryan groth" <postgres(at)cpusoftware(dot)com>, "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>, "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Joins and full index scans...mysql vs postgres? |
| Date: | 2006-02-22 23:18:58 |
| Message-ID: | op.s5edpwbncigqcu@apollo13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> "997+3522 ms". Am I reading these numbers wrong? Are these numbers
> reflective of application performance? Is there an optimization I am
> missing?
It also reflects the time it takes to pgadmin to insert the results into
its GUI...
If you want to get an approximation of the time the server needs to
process your request, without the data marshalling time on the network and
anything, you can either use EXPLAIN ANALYZE (but mysql doesn't have it,
and the instrumentation adds overhead), or simply something like "SELECT
sum(1) FROM (query to benchmark)", which only returns 1 row, and the sum()
overhead is minimal, and it works on most databases. I find it useful
because in knowing which portion of the time is spent by the server
processing the query, or in data transfer, or in data decoding on the
client side, or simply in displaying...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris | 2006-02-22 23:58:39 | Re: Joins and full index scans...mysql vs postgres? |
| Previous Message | Orion | 2006-02-22 22:07:35 | Re: Large Database Design Help |