Re: UPDATEDs slowing SELECTs in a fully cached database
От | Merlin Moncure |
---|---|
Тема | Re: UPDATEDs slowing SELECTs in a fully cached database |
Дата | |
Msg-id | CAHyXU0wN0i=vDnC_VeB3pp956Gr_Xxe82MJ-7ojJnPOeu0eFHQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: UPDATEDs slowing SELECTs in a fully cached database (lars <lhofhansl@yahoo.com>) |
Список | 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 по дате отправления: