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 по дате отправления: