Re: Index Scans become Seq Scans after VACUUM ANALYSE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com>
Cc: Curt Sampson <cjs(at)cynic(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date: 2002-06-24 21:16:01
Message-ID: 21376.1024953361@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"J. R. Nield" <jrnield(at)usol(dot)com> writes:
> Also, postgreSQL can't recover from any other type of block corruption,
> while the commercial systems can.

Say again?

> Would it not be the case that things like read-ahead, grouping writes,
> and caching written data are probably best done by PostgreSQL, because
> only our buffer manager can understand when they will be useful or when
> they will thrash the cache?

I think you have been missing the point. No one denies that there will
be some incremental gain if we do all that. However, the conclusion of
everyone who has thought much about it (and I see Curt has joined that
group) is that the effort would be far out of proportion to the probable
gain. There are a lot of other things we desperately need to spend time
on that would not amount to re-engineering large quantities of OS-level
code. Given that most Unixen have perfectly respectable disk management
subsystems, we prefer to tune our code to make use of that stuff, rather
than follow the "conventional wisdom" that databases need to bypass it.

Oracle can afford to do that sort of thing because they have umpteen
thousand developers available. Postgres does not.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-06-24 21:25:14 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Tom Lane 2002-06-24 21:02:37 Re: [HACKERS] pg_restore: [archiver] input file does not appear to be a valid archive