Re: UPDATEDs slowing SELECTs in a fully cached database

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: UPDATEDs slowing SELECTs in a fully cached database
Дата
Msg-id 464.1310658420@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
Список pgsql-performance
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It seems like we ought to distinguish heap cleanup activities from
>> user-visible semantics (IOW, users shouldn't care if a HOT cleanup
>> has to be done over after restart, so if the transaction only
>> wrote such records there's no need to flush).  This'd require more
>> process-global state than we keep now, I'm afraid.

> That makes sense, and seems like the right long-term fix.  It seems
> like a boolean might do it; the trick would be setting it (or not)
> in all the right places.

The implementation I was imagining was to define another bit in the info
parameter for XLogInsert, say XLOG_NON_TRANSACTIONAL.  This could be a
high-order bit that would not go to disk.  Anytime it was *not* set,
XLogInsert would set a global boolean that would remember that the
current transaction wrote a transactional WAL record.  This is the
right default since the vast majority of call sites are writing records
that we would want to have flushed at commit.  There are just a couple
of places that would need to be changed to add this flag to their calls.

            regards, tom lane

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

Предыдущее
От: Robert Klemme
Дата:
Сообщение: Re: UPDATEDs slowing SELECTs in a fully cached database
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: UPDATEDs slowing SELECTs in a fully cached database