| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)uk> |
| Cc: | Michiel Lange <michiel(at)minas(dot)demon(dot)nl>, "Chris G(dot) Nicholas" <cgn(at)globexplorer(dot)com>, "" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: big tables with lots-o-rows |
| Date: | 2003-07-01 14:36:00 |
| Message-ID: | 2939.1057070160@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)uk> writes:
> On Tue, 1 Jul 2003, Tom Lane wrote:
>> None of that has the slightest relevance to Postgres, however, since we
>> always split large tables into gigabyte-sized segment files.
> I was under the impression that largefile would make the DB store data
> in larger files, where appropriate,
It does not. (There is a manual compile-time option to turn off the
splitting, but the non-split code paths haven't been exercised in years,
and quite honestly I wouldn't trust them.)
> For example, running out of inodes is also reported as out-of-space.
Excellent thought ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan Gardner | 2003-07-01 15:22:37 | Re: replication/redundancy |
| Previous Message | Derek Main | 2003-07-01 14:33:12 | zero (o) return code on failure of pg_dump |