| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
| Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-07 15:26:32 |
| Message-ID: | 20090507152632.GD3026@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Dimitri escribió:
> As well when you look on profiling technology - all such kind of
> solutions are based on the system clock frequency and have their
> limits on time resolution. On my system this limit is 0.5ms, and it's
> too big comparing to the query execution time :-)
>
> So, what I've done - I changed little bit a reference key criteria from
> = '0000000001' to < '0000000051', so instead of 20 rows I have 1000
> rows on output now,
Another thing you can try is run the query several times (like 10000 or so).
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikolas Everett | 2009-05-07 15:37:52 | Re: Slow select performance despite seemingly reasonable query plan |
| Previous Message | Matthew Wakeling | 2009-05-07 15:19:15 | Re: Slow select performance despite seemingly reasonable query plan |