From: | mlw <markw(at)mohawksoft(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Curt Sampson <cjs(at)cynic(dot)net>, Michael Loftis <mloftis(at)wgops(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index Scans become Seq Scans after VACUUM ANALYSE |
Date: | 2002-04-25 18:13:40 |
Message-ID: | 3CC84754.CCD19D28@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Now, with larger RAM and disk sizes, it may be time to consider larger
> page sizes, like 32k pages. That reduces the granularity of the cache,
> but it may have other performance advantages that would be worth it.
>
> What people are actually suggesting with the read-ahead for sequential
> scans is basically a larger block size for sequential scans than for
> index scans. While this makes sense, it may be better to just increase
> the block size overall.
I have seen performance improvements by using 16K blocks over 8K blocks in
sequential scans of large tables.
I am investigating the performance difference between 16K and 8K block sizes on
one of my systems. I'll let you know what I see. I am using pgbench for generic
performance levels.
If you would like to see any extra data, just let me know.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-25 18:26:01 | Re: Vote totals for SET in aborted transaction |
Previous Message | Marc G. Fournier | 2002-04-25 17:59:43 | Re: Vote totals for SET in aborted transaction |