Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Any better plan for this query?..
Дата
Msg-id 1242674854.14551.56.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Ответы Re: Any better plan for this query?..  ("Dave Dutcher" <dave@tridecap.com>)
Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Re: Any better plan for this query?..  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-performance по дате отправления:

Предыдущее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Scott Carey
Дата:
Сообщение: Re: Any better plan for this query?..