Re: [HACKERS] tables > 1 gig
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] tables > 1 gig |
Дата | |
Msg-id | 376C33C4.A623F476@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] tables > 1 gig (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] tables > 1 gig
|
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> Then we'd better fix the underlying problem. We can't change > >> RELSEG_SIZE for a minor release, unless you want to give up the > >> principle of not forcing initdb at minor releases. > > Why can't we increase it? > Consider a 1.5-gig table. 6.5 will store it as one gig in file "table", > one-half gig in file "table.1". Now recompile with larger RELSEG_SIZE. > The file manager will now expect to find all blocks of the relation in > file "table", and will never go to "table.1" at all. Presto, you lost > a bunch of data. > Bottom line is just as it says in the config.h comments: you can't > change either BLCKSZ or RELSEG_SIZE without doing initdb. Sorry for backing up so far on this thread... Would it be possible to make BLCKSZ and/or RELSEG_SIZE (the latter perhaps the most important, and perhaps the easiest?) a configurable parameter which is read out of a global variable for each database? If so, we could later think about moving it, along with things like "default character set", to pg_database as per-db information, and make it an option on CREATE DATABASE. That kind of thing might make in-place upgrades easier too. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: