Bruce Momjian wrote
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If the TODO-list-with-dash isn't the correct place to have looked,
is
there another list of committed changes for the next release?
We tend to rely on the CVS commit logs as the definitive source.
You
can
Jan,
Happy to continue the discussion...though without changing my suggestion
that we defer any further more specialised improvements for now.
Jan Wieck replied to...
Simon Riggs wrote:
If we know ahead of time that a large scan is going to have this
effect,
why wait for the ARC to play
Simon Riggs wrote:
Jan,
[...]
My thoughts are about multiple concurrent accesses, specifically FTS on
large tables, rather than sequential ones.
Single or multiple backends is irrelevant here because a data block only
exists once, and therefore we have only one shared buffer cache.
Buffers
Jan,
I think we should suspend further discussion for now...in summary:
ARC Buffer management is an important new performance feature for 7.5;
the implementation is a good one and should have positive benefit for
everybody's workload. ARC will adapt to a variety of situations and has
been
Jan Wieck wrote:
have you read src/backend/storage/buffer/README of current CVS tip?
Tom Lane wrote:
Um, did you read the discussion of the ARC buffer management algorithm
that's already been implemented for 7.5?
Tom, Jan,
No, I hadn't read this. Thank you both for your time and
Jan Wieck wrote:
have you read src/backend/storage/buffer/README of current CVS tip?
The algorithm in the new replacement strategy is an attempt to figure
that SMALL_TABLE_THRESHOLD automatically. Do you see anything that can
be improved in that algorithm?
Jan,
I've read
Simon Riggs [EMAIL PROTECTED] writes:
If the TODO-list-with-dash isn't the correct place to have looked, is
there another list of committed changes for the next release?
We tend to rely on the CVS commit logs as the definitive source. You
can pull the info from the CVS server (I use cvs2cl.pl
Simon,
have you read src/backend/storage/buffer/README of current CVS tip?
The algorithm in the new replacement strategy is an attempt to figure
that SMALL_TABLE_THRESHOLD automatically. Do you see anything that can
be improved in that algorithm?
Jan
Simon Riggs wrote:
This discussion seems
Simon Riggs [EMAIL PROTECTED] writes:
Any comments?? Takers?
Um, did you read the discussion of the ARC buffer management algorithm
that's already been implemented for 7.5?
The main objection I have to doing it Oracle's way is that that creates
more parameters that DBAs have to get right for
On Fri, Jan 16, 2004 at 12:00:08PM -0500, Michael Brusser wrote:
Is there a way to force database to load
a frequently-accessed table into cache and keep it there?
If it is frequently accessed, I guess it would be in the cachke
permanently
--
Is there a way to force database to load
a frequently-accessed table into cache and keep it there?
Thanks,
Mike.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Michael Brusser [EMAIL PROTECTED] writes:
Is there a way to force database to load a frequently-accessed table
into cache and keep it there?
No.
BTW, this idea has been suggested in the past, so check the archives
for the prior discussions on this topic. The usual response is that
the
On Fri, 16 Jan 2004, Michael Brusser wrote:
Is there a way to force database to load
a frequently-accessed table into cache and keep it there?
Nope. But there is a new cache buffer handler that may make it into 7.5
that would make that happen automagically.
---(end
13 matches
Mail list logo
