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
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 |