On Tue, 2006-06-13 at 15:00 +0200, Martijn van Oosterhout wrote:
> What you might be able to do is to reduce its effect. The thing that
> occurs to me is to make hint bit changes only mark a page half-dirty.
> If the page is evicted because the space is needed in the buffer cache,
> it can be just
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> What you are seeing is the now infamous "Postgres writes a table one more
> time after loading" behavior.
> Tom - can you explain what's going on with this?
Setting XMIN_COMMITTED hint bits.
regards, tom lane
Martin,
On 6/13/06 6:00 AM, "Martijn van Oosterhout" wrote:
> What you might be able to do is to reduce its effect. The thing that
> occurs to me is to make hint bit changes only mark a page half-dirty.
> If the page is evicted because the space is needed in the buffer cache,
> it can be just dr
On Tue, Jun 13, 2006 at 05:46:23AM -0700, Luke Lonergan wrote:
> Martin,
>
> On 6/13/06 5:42 AM, "Martijn van Oosterhout" wrote:
>
> > Is it possible it may have something to do with the hint bits? There's
> > are a bunch of bits in the header to deal with speeding up of MVCC
> > tests. Maybe ch
Martin,
On 6/13/06 5:42 AM, "Martijn van Oosterhout" wrote:
> Is it possible it may have something to do with the hint bits? There's
> are a bunch of bits in the header to deal with speeding up of MVCC
> tests. Maybe changing those bits marks the page dirty and forces a
> write?
Yes, that's it.
On Tue, Jun 13, 2006 at 04:54:05AM -0700, Luke Lonergan wrote:
> > Experimental results here suggest that for larger tables Linux seems
> > to detect a seq-scan and not bother caching. It's very reproducible
> > for me here to do a reboot and not see the full speedup on a seq_scan
> > until the t
Ron,
On 6/8/06 11:49 AM, "Ron Mayer" <[EMAIL PROTECTED]> wrote:
> Experimental results here suggest that for larger tables Linux seems
> to detect a seq-scan and not bother caching. It's very reproducible
> for me here to do a reboot and not see the full speedup on a seq_scan
> until the third
Ron Mayer <[EMAIL PROTECTED]> writes:
> Does running a query only twice really insure that a result is cached?
> It seems not to be the case for seq-scans on Linux.
Should work for tables small enough to fit into the shared_buffers
arena. I wouldn't necessarily assume it for large tables.
No
Tom Lane wrote:
-- do it again to ensure fully cached
bench=# select count(*) from accounts;
Short summary:
Does running a query only twice really insure that a result is cached?
It seems not to be the case for seq-scans on Linux.
I think this may matters to the discussions about a readahe
