| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-18 19:27:34 |
| Message-ID: | 1242674854.14551.56.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, 2009-05-18 at 20:00 +0200, Dimitri wrote:
> >From my point of view it needs first to understand where the time is
> wasted on a single query (even when the statement is prepared it runs
> still slower comparing to MySQL).
There is still a significant number of things to say about these numbers
and much tuning still to do, so I'm still confident of improving those
numbers if we needed to.
In particular, running the tests repeatedly using
H.REF_OBJECT = '0000000001'
rather than varying the value seems likely to benefit MySQL. The
distribution of values is clearly non-linear; while Postgres picks a
strange plan for that particular value, I would guess there are also
values for which the MySQL plan is sub-optimal. Depending upon the
distribution of selected data we might see the results go either way.
What I find worrying is your result of a scalability wall for hash
joins. Is that a repeatable issue?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Carey | 2009-05-18 19:37:48 | Re: Any better plan for this query?.. |
| Previous Message | Dimitri | 2009-05-18 18:00:59 | Re: Any better plan for this query?.. |