Zeugswetter Andreas SB SD wrote:
>
> > The random_page_cost is changed because of an assumption that the
> bigger systems
> > will be more busy. The more busy a machine is doing I/O the lower the
> differential
> > between a sequential and random access. ("sequential" to the
> application is less
> > likely sequential to the physical disk.)
>
> I think this reasoning is valid, but would we then not rather need
> something like
> a scan_page_cost, that would need to be raised ? Or are the CPU costs so
> small,
> that only the relation between scan and random counts ?
From what I can gather, "sequential scan" of next block is the base unit. All
other measurements are based off this constant. What that constant is, I don't
know.
>
> > I'd like to open a debate about the benefit/cost of shared_buffers.
> The question
> > is: "Will postgres' management of shared buffers out perform O/S
> cache? Is there a
> > point of diminishing return on number of buffers? If so, what?
>
> I think the main point for PostgreSQL buffers is to account for "dirty"
> pages.
> This only because we use OS files and can thus rely on OS file caching.
> If your application is update intensive, then you should have sufficient
> buffers to hold most dirtied pages between checkpoints. Does that make
> sense ?
Actually this is something to think about. If Bruce implemented his removal of
caching for seqential scans of tables, then the postgres cache should out
perform OS cache if you are doing seqential scans. I would also be curious
about the cost differential between reading a block vs scaning postgres' cache.
Getting a block out of postgres' cache requires searching the cache, getting a
block for OS cache requires similar action within the OS, as well as, the OS
hit, and the work required to put it in cache including the memory allocation.
I will grant that the applications for which we are using Postgres use some
very odd queries, but I can see 80% cache hit rates if the statistics are
right.