Rod Taylor wrote:
| 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 replac
> | 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
>
-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 m
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
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 l
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???
---(end of broadcast)---
TIP 3: if posting/reading through U
