Re: Big 7.1 open items

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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