-----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-----
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
