>
> Well, my plans for 6.4:
>
> 1. Btree: use TID as (last) part of index key; prepare btree
> for low-level locking (it's now possible to lose root page).
> 2. Vacuum: speed up index cleaning; release pg_class lock after
> updation statistic for a table.
> 3. Buffer manager: error handling broken; should flush only
> buffers changed by backend itself.
> 4. Implement shared catalog cache; get rid of invalidation code.
> 5. Subselects: in target list; in FROM.
> 6. Transaction manager: get rid of pg_variable; do not prefetch
> XIDs; nested transactions; savepoints.
That's quite a list.
Vadim, I hate to ask, but how about the buffering of pg_log writes and
the ability to do sync() every 30 seconds then flush pg_log, so we can
have crash reliability without doing fsync() on every transaction.
We discussed this months ago, and I am not sure if you were thinking of
doing this for 6.4. I can send the old posts if that would help. It
would certainly increase our speed vs. fsync().
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)