Re: MySQL versus Postgres

Поиск
Список
Период
Сортировка
От Sandeep Srinivasa
Тема Re: MySQL versus Postgres
Дата
Msg-id AANLkTikfct=iTd3hb9h1BWc8448sANSpujA0d+aT5Mvf@mail.gmail.com
обсуждение исходный текст
Ответ на Re: MySQL versus Postgres  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-general


On Thu, Aug 12, 2010 at 12:37 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Wed, Aug 11, 2010 at 11:41 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Sandeep Srinivasa wrote:
>>
>>  Maybe a tabular form would be nice - "work_mem" under...
>
> The problem with work_mem in particular is that the useful range depends
> quite a bit on how complicated you expect the average query running to be.

And it's very dependent on max connections.  A machine with 512GB that
runs batch processes for one or two import processes and then has
another two or three used to query it can run much higher work_mem
than a machine with 32G set to handle hundreds of concurrent accesses.
 Don't forget that when you set work_mem to high it has a very sharp
dropoff in performance as swapping starts to occur.  If work_mem is a
little low, queries run 2 or 3 times slower.  If it's too high the
machine can grind to a halt.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Right there - could this information not have been captured in the tabular form I was talking about ? Again, I'm not sure how to present the data, but it sure would be of *some* help to the next poor soul who comes along with same question.

This here is golden knowledge - yes you might not be able to add all the qualifiers to just saying ">8GB use X work_mem", but it really, really is much better than nothing that we have now.

-Sandeep


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Is there a way too speed up Limit with high OFFSET ?
Следующее
От: Mike Christensen
Дата:
Сообщение: Re: Converting join'ed rows into a comma or space delimited list