From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | Iain <iain(at)mst(dot)co(dot)jp> |
Cc: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org>, Mark Aufflick <mark(at)pumptheory(dot)com> |
Subject: | Re: seq scan cache vs. index cache smackdown |
Date: | 2005-02-15 04:20:51 |
Message-ID: | 1108441251.67118.111.camel@home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> My concern is that this kind of testing has very little relevance to the
> real world of multiuser processing where contention for the cache becomes an
> issue. It may be that, at least in the current situation, postgres is
> giving too much weight to seq scans based on single user, straight line
To be fair, a large index scan can easily throw the buffers out of whack
as well. An index scan on 0.1% of a table with 1 billion tuples will
have a similar impact to buffers as a sequential scan of a table with 1
million tuples.
Any solution fixing buffers should probably not take into consideration
the method being performed (do you really want to skip caching a
sequential scan of a 2 tuple table because it didn't use an index) but
the volume of data involved as compared to the size of the cache.
I've often wondered if a single 1GB toasted tuple could wipe out the
buffers. I would suppose that toast doesn't bypass them.
--
Rod Taylor <pg(at)rbt(dot)ca>
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2005-02-15 04:54:46 | Re: seq scan cache vs. index cache smackdown |
Previous Message | Iain | 2005-02-15 03:55:33 | Re: seq scan cache vs. index cache smackdown |