-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Marlowe wrote:
| On Mon, 2004-08-02 at 10:43, Gaetano Mendola wrote:
|
|>Scott Marlowe wrote:
|>
|>>On Mon, 2004-08-02 at 02:11, Ioannis Theoharis wrote:
|>>
|>>
|>>>Hi, i would like to answer if there is any way in postgres to find the
|>>>page miss hits caused during a query execution.
|>>>
|>>>
|>>>Is there something like explain analyze with the page miss hits???
|>>
|>>
|>>You're making a basic assumption that is (at least currently) untrue,
|>>and that is that PostgreSQL has it's own cache.
|>
|>Are you sure of this ? What is the meaning of the ARC recently introduced
|>then ?
|
|
| Yes I am. Test it yourself, setup a couple of backends, select * from
| some big tables, then, one at a time, shut down the psql clients and
| when the last one closes, the shared mem goes away. Run another client,
| do select * from the big table, and watch the client size grow from a
| few meg to a size large enough to hold the whole table (or however much
| your shared_buffers will hold.)
|
| While someone may make ARC and the shared buffers act like a cache some
| day (can't be that hard, most of the work is done really) right now it's
| not how it works.
|
| ARC still helps, since it makes sure the shared_buffers don't all get
| flushed from the useful small datasets when a seq scan gets executed.
I'm still not convinced. Why the last backend alive, have to throw away
bunch of memory copied in the SHM? And again, the ARC is a replacement
policy for a cache, which one ?
Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBDqkL7UpzwH2SGd4RAsQFAKCWVpCXKgRfE1nc44ZmtEaIrtNaIQCgr4fd
Hx2NiuRzV0UQ3Na9g/zQbzE=
=XWua
-----END PGP SIGNATURE-----
