On Sat, Jan 14, 2006 at 04:13:56PM -0500, Qingqing Zhou wrote:
Qingqing Zhou [EMAIL PROTECTED] wrote
I wonder if we should really implement file-system-cache-warmup strategy
which we have discussed before. There are two natural good places to do
this:
(1) sequentail scan
(2)
Qingqing Zhou [EMAIL PROTECTED] wrote
I wonder if we should really implement file-system-cache-warmup strategy
which we have discussed before. There are two natural good places to do
this:
(1) sequentail scan
(2) bitmap index scan
For the sake of memory, there is a third place a warm-up
On Sat, 7 Jan 2006, Greg Stark wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
For b1, it actually doesn't matter much though. With bitmap we definitely
can give a better EXPLAIN numbers for seqscan only, but without the bitmap,
we seldom make wrong choice of choosing/not choosing
Qingqing Zhou [EMAIL PROTECTED] writes:
In other words, the difference between being in Postgres's buffer cache and
being in the filesystem cache, while not insignificant, isn't really
relevant
to the planner since it affects sequential scans and index scans equally.
The bitmap was
Greg Stark [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hm. Personally I have a hunch you're right. But there we have no actual
evidence. The first thing that needs to happen is changes to use O_DIRECT
for
everything and then benchmarking one of those big TPC tests with the
Qingqing Zhou [EMAIL PROTECTED] wrote
Feasibility: Our bufmgr lock rewrite already makes this possible. But to
enable it, we may need more work: (w1) make bufferpool relation-wise,
which makes our estimation of data page residence more easy and reliable.
(w2) add aggresive pre-read on buffer
Qingqing Zhou [EMAIL PROTECTED] writes:
For b1, it actually doesn't matter much though. With bitmap we definitely
can give a better EXPLAIN numbers for seqscan only, but without the bitmap,
we seldom make wrong choice of choosing/not choosing sequential scan.
I think you have a more
Hinted by this thread:
http://archives.postgresql.org/pgsql-performance/2006-01/msg00016.php
I wonder if we should really implement file-system-cache-warmup strategy
which we have discussed before. There are two natural good places to do
this:
(1) sequentail scan
(2)
Qingqing Zhou [EMAIL PROTECTED] writes:
Hinted by this thread:
http://archives.postgresql.org/pgsql-performance/2006-01/msg00016.php
I wonder if we should really implement file-system-cache-warmup strategy
which we have discussed before.
The difference between the cached and non-cached
On Thu, 5 Jan 2006, Tom Lane wrote:
The difference between the cached and non-cached states is that the
kernel has seen fit to remove those pages from its cache. It is
reasonable to suppose that it did so because there was a more immediate
use for the memory. Trying to override that
On Thu, 5 Jan 2006, Qingqing Zhou wrote:
Feasibility: Our bufmgr lock rewrite already makes this possible. But to
enable it, we may need more work: (w1) make bufferpool relation-wise,
which makes our estimation of data page residence more easy and reliable.
(w2) add aggresive pre-read on
11 matches
Mail list logo
