Re: UPDATEDs slowing SELECTs in a fully cached database

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: UPDATEDs slowing SELECTs in a fully cached database
Дата
Msg-id CAHyXU0x4bCecWRdpRGypckHHfkZiBCv3=7rCqMswcHj3hRYMjA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-performance
On Tue, Jul 12, 2011 at 9:36 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> lars <lhofhansl@yahoo.com> wrote:
>
>> I am not trying to optimize this particular use case, but rather
>> to understand what Postgres is doing, and why SELECT queries are
>> affected negatively (sometimes severely) by concurrent (or even
>> preceding) UPDATEs at all when the database resides in the cache
>> completely.
>
> I think we're stuck in terms of trying to guess what is causing the
> behavior you are seeing.  Things which would help get it "unstuck":
>
> (1)  More information about your load process.  Looking at the code,
> I could sort of see a possible path to this behavior if the load
> process involves any adjustments beyond straight INSERTs or COPYs
> in.
>
> (2)  You could poke around with a profiler, a debugger, and/or
> the contrib/pageinspect module to sort things out.


hm, also strace on the 'select' process might give some clues.

merlin

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

Предыдущее
От: Gael Le Mignot
Дата:
Сообщение: Re: Memory usage of auto-vacuum
Следующее
От: Mario Splivalo
Дата:
Сообщение: Planner choosing NestedLoop, although it is slower...