Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Any better plan for this query?..
Дата
Msg-id 603c8f070905121057u89ca62bw16ce307452e511b6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Any better plan for this query?..
Список pgsql-performance
On Tue, May 12, 2009 at 1:00 PM, Dimitri <dimitrik.fr@gmail.com> wrote:
> On MySQL there is no changes if I set the number of sessions in the
> config file to 400 or to 2000 - for 2000 it'll just allocate more
> memory.

I don't care whether the setting affects the speed of MySQL.  I want
to know if it affects the speed of PostgreSQL.

> After latest fix with default_statistics_target=5, version 8.3.7 is
> running as fast as 8.4, even 8.4 is little little bit slower.
>
> I understand your position with a pooler, but I also want you think
> about idea that 128 cores system will become a commodity server very
> soon, and to use these cores on their full power you'll need a
> database engine capable to run 256 users without pooler, because a
> pooler will not help you here anymore..

So what?  People with 128-core systems will not be running trivial
joins that return in 1-2ms and have one second think times between
them.  And if they are, and if they have nothing better to do than
worry about whether MySQL can process those queries in 1/2000th of the
think time rather than 1/1000th of the think time, then they can use
MySQL.  If we're going to worry about performance on 128-core system,
we would be much better advised to put our efforts into parallel query
execution than how many microseconds it takes to execute very simple
queries.

Still, I have no problem with making PostgreSQL faster in the case
you're describing.  I'm just not interested in doing it on my own time
for free.  I am sure there are a number of people who read this list
regularly who would be willing to do it for money, though.  Maybe even
me.  :-)

...Robert

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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Rafael Martinez
Дата:
Сообщение: Re: Query planner making bad decisions