Re: UPDATEDs slowing SELECTs in a fully cached database

From: Tom Lane
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: ,
Msg-id: 11679.1310595677@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner")
Responses: Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner")
List: pgsql-performance

Tree view

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 by date:

From: lars
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
From: alan
Date:
Subject: Trigger or Function