On Tue, Jul 12, 2011 at 9:36 AM, Kevin Grittner <Kevin.Grittner@xxxxxxxxxxxx> wrote: > lars <lhofhansl@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
