Re: Index Scans become Seq Scans after VACUUM ANALYSE

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.

In response to

Browse pgsql-hackers by date

  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