From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Subject: | Re: Big 7.1 open items |
Date: | 2000-06-16 23:30:25 |
Message-ID: | 9317.961198225@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> It seems that we should also provide not_preallocated DATAFILE
> when many_tables_in_a_file storage manager is introduced.
Several people in this thread have been talking like a
single-physical-file storage manager is in our future, but I can't
recall anyone saying that they were going to do such a thing or even
presenting reasons why it'd be a good idea.
Seems to me that physical file per relation is considerably better for
our purposes. It's easier to figure out what's going on for admin and
debug work, it means less lock contention among different backends
appending concurrently to different relations, and it gives the OS a
better shot at doing effective read-ahead on sequential scans.
So why all the enthusiasm for multi-tables-per-file?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-16 23:43:10 | Re: Bug with views and defaults |
Previous Message | Randall Parker | 2000-06-16 23:18:23 | Re: Re: Big 7.1 open items |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-17 00:08:21 | Re: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-16 23:16:37 | Re: Big 7.1 open items |