Re: Index Scans become Seq Scans after VACUUM ANALYSE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Index Scans become Seq Scans after VACUUM ANALYSE
Дата
Msg-id 21376.1024953361@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Curt Sampson <cjs@cynic.net>)
Ответы Re: Index Scans become Seq Scans after VACUUM ANALYSE  ("J. R. Nield" <jrnield@usol.com>)
Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Curt Sampson <cjs@cynic.net>)
Список pgsql-hackers
"J. R. Nield" <jrnield@usol.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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Kalchev
Дата:
Сообщение: oids rollover?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_restore: [archiver] input file does not appear to be a valid archive