Re: UPDATEDs slowing SELECTs in a fully cached database - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: UPDATEDs slowing SELECTs in a fully cached database
Date
Msg-id CAHyXU0wN0i=vDnC_VeB3pp956Gr_Xxe82MJ-7ojJnPOeu0eFHQ@mail.gmail.com
Whole thread Raw
In response to Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
List pgsql-performance
On Wed, Jul 13, 2011 at 1:10 PM, lars <lhofhansl@yahoo.com> wrote:
> On 07/13/2011 08:17 AM, Tom Lane wrote:
>>
>> "Kevin Grittner"<Kevin.Grittner@wicourts.gov>  writes:
>>>
>>> ...  Jeff does raise a good point, though -- it seems odd
>>> that WAL-logging of this pruning would need to be synchronous.
>>
>> Yeah, we need to get to the bottom of that.  If there's enough
>> shared_buffer space then it shouldn't be.
>
> This thread has gotten long, let me try to compile all the relevant
> information in one email.
>
> \d test
>            Table "lars.test"
>    Column    |     Type      | Modifiers
> --------------+---------------+-----------
>  tenant       | character(15) |
>  created_by   | character(15) |
>  created_date | date          |

small aside here: try to avoid use of character(n) type -- varchar(n)
is superior in every way, including performance (although that has
nothing to do with your WAL issues on this thread).

merlin

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Next
From: "Kevin Grittner"
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database