Question regarding the operation of the shared_buffers cache and implications
of the pg_X_stat_tables|pg_X_stat_indexes stats.
( I am also aware that this is all complicated by the kernel cache behavior,
however, if, for the purpose of these questions, you wouldn't mind assuming
that we don't ha
Mark Rostron wrote:
What is the procedure that postgres uses to decide whether or not a
table/index block will be left in the shared_buffers cache at the end
of the operation?
There is no such procedure. When a table or index page is used, its
usage count goes up, which means it's more l
Marti Raudsepp wrote:
I will grant you that the details were wrong, but I stand by the conclusion.
I can state for a fact that PostgreSQL's default wal_sync_method
varies depending on the header.
Yes; it's supposed to, and that logic works fine on some other
platforms. The question is exa
On Monday 08 November 2010 00:35:29 Greg Smith wrote:
> Marti Raudsepp wrote:
> > I will grant you that the details were wrong, but I stand by the
> > conclusion. I can state for a fact that PostgreSQL's default
> > wal_sync_method varies depending on the header.
>
> Yes; it's supposed to, and th
Andres Freund wrote:
I think thats FUD. Sorry.
Yes, there's plenty of uncertainty and doubt here, but not from me. The
test reports given so far have been so riddled with errors I don't trust
any of them.
As a counter example showing my expectations here, the "Testing
Sandforce SSD" te
> >
> > What is the procedure that postgres uses to decide whether or not a
> > table/index block will be left in the shared_buffers cache at the end
> > of the operation?
> >
>
> The only special cases are for sequential scans and VACUUM, which use
> continuously re-use a small section of the b
On Mon, Nov 8, 2010 at 01:35, Greg Smith wrote:
> Yes; it's supposed to, and that logic works fine on some other platforms.
No, the logic was broken to begin with. Linux technically supported
O_DSYNC all along. PostgreSQL used fdatasync as the default. Now,
because Linux added proper O_SYNC suppo
2010/11/8 Mark Rostron :
>> >
>> > What is the procedure that postgres uses to decide whether or not a
>> > table/index block will be left in the shared_buffers cache at the end
>> > of the operation?
>> >
>>
>> The only special cases are for sequential scans and VACUUM, which use
>> continuously
