Re: UPDATEDs slowing SELECTs in a fully cached database

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: UPDATEDs slowing SELECTs in a fully cached database
Дата
Msg-id 21639.1310519797@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: UPDATEDs slowing SELECTs in a fully cached database  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance
Jeff Janes <jeff.janes@gmail.com> writes:
> On 7/12/11, lars <lhofhansl@yahoo.com> wrote:
>> The fact that a select (maybe a big analytical query we'll run) touching
>> many rows will update the WAL and wait
>> (apparently) for that IO to complete is making a fully cached database
>> far less useful.
>> I just artificially created this scenario.

> I can't think of any reason that that WAL would have to be flushed
> synchronously.

Maybe he's running low on shared_buffers?  We would have to flush WAL
before writing a dirty buffer out, so maybe excessive pressure on
available buffers is part of the issue here.

            regards, tom lane

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

Предыдущее
От: Mario Splivalo
Дата:
Сообщение: Re: Planner choosing NestedLoop, although it is slower...
Следующее
От: Mario Splivalo
Дата:
Сообщение: Re: Planner choosing NestedLoop, although it is slower...