Re: UPDATEDs slowing SELECTs in a fully cached database

От: Tom Lane
Тема: Re: UPDATEDs slowing SELECTs in a fully cached database
Дата: ,
Msg-id: 11679.1310595677@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner")
Ответы: Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner")
Список: pgsql-performance

Скрыть дерево обсуждения

UPDATEDs slowing SELECTs in a fully cached database  (lars, )
 Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
  Re: UPDATEDs slowing SELECTs in a fully cached database  (Craig Ringer, )
   Re: UPDATEDs slowing SELECTs in a fully cached database  (lars hofhansl, )
    Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
     Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
      Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
       Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
        Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
         Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
        Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
         Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
          Re: UPDATEDs slowing SELECTs in a fully cached database  (Ivan Voras, )
           Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
            Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
             Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
              Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
              Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
               Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
                Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
               Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
                Re: UPDATEDs slowing SELECTs in a fully cached database  (Tom Lane, )
                 Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
                  Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
                  Re: UPDATEDs slowing SELECTs in a fully cached database  (Jeff Janes, )
                 Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
                  Re: UPDATEDs slowing SELECTs in a fully cached database  (Tom Lane, )
                   Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
                    Re: UPDATEDs slowing SELECTs in a fully cached database  (Robert Klemme, )
                    Re: UPDATEDs slowing SELECTs in a fully cached database  (Tom Lane, )
                     Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
                Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
                 Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
                  Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
                   Re: UPDATEDs slowing SELECTs in a fully cached database  (Jeff Janes, )
                    Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
                     Re: UPDATEDs slowing SELECTs in a fully cached database  (Jeff Janes, )
                      Re: UPDATEDs slowing SELECTs in a fully cached database  (Greg Smith, )
              Re: UPDATEDs slowing SELECTs in a fully cached database  (Jeff Janes, )
               Re: UPDATEDs slowing SELECTs in a fully cached database  (Tom Lane, )
             Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
              Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
               Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
                Re: UPDATEDs slowing SELECTs in a fully cached database  (Pavan Deolasee, )
                 Re: UPDATEDs slowing SELECTs in a fully cached database  (lars hofhansl, )
                  Re: UPDATEDs slowing SELECTs in a fully cached database  (Jeff Janes, )
            Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
 Re: UPDATEDs slowing SELECTs in a fully cached database  ("", )
  Re: UPDATEDs slowing SELECTs in a fully cached database  (Robert Klemme, )
   Re: UPDATEDs slowing SELECTs in a fully cached database  ("", )
   Re: UPDATEDs slowing SELECTs in a fully cached database  (lars, )
    Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner", )
     Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
 Re: UPDATEDs slowing SELECTs in a fully cached database  (Ivan Voras, )
  Re: UPDATEDs slowing SELECTs in a fully cached database  (Merlin Moncure, )
   Re: UPDATEDs slowing SELECTs in a fully cached database  (Ivan Voras, )
 Re: UPDATEDs slowing SELECTs in a fully cached database  (Lars, )

"Kevin Grittner" <> writes:
> Tom Lane <> wrote:
>> Huh?  If there was never an XID, there's no commit WAL record,
>> hence nothing to make asynchronous.

> If you look at the RecordTransactionCommit() function in xact.c
> you'll see that's not correct.

Oh, hmmm ... that code was written with the idea that things like
sequence XLOG_SEQ_LOG records ought to be flushed to disk before
reporting commit; otherwise you don't have a guarantee that the same
sequence value couldn't be handed out again after crash/restart,
in a transaction that just does something like
    SELECT nextval('myseq');
without any updates of regular tables.

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.

Another approach we could take (also nontrivial) is to prevent
select-only queries from doing HOT cleanups.  You said upthread that
there were alleged performance benefits from aggressive cleanup, but
IMO that can charitably be described as unproven.  The real reason it
happens is that we didn't see a simple way for page fetches to know soon
enough whether a tuple update would be likely to happen later, so they
just do cleanups unconditionally.

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: lars
Дата:
Сообщение: Re: UPDATEDs slowing SELECTs in a fully cached database
От: alan
Дата:
Сообщение: Trigger or Function