| From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Greg Stark" <gsstark(at)mit(dot)edu>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: sync_file_range() |
| Date: | 2006-06-20 09:43:22 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA5790116C303@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Indeed, I've been wondering lately if we shouldn't resurrect
> > LET_OS_MANAGE_FILESIZE and make that the default on systems with
> > largefile support. If nothing else it would cut down on open/close
> > overhead on very large relations.
I'd still put some limit on the filesize, else you cannot manually
distribute a table across spindles anymore. Also some backup solutions
are not too happy with too large files eighter (they have trouble
with staging the backup). I would suggest something like 32 Gb.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ohp | 2006-06-20 09:50:55 | pltcl -- solved |
| Previous Message | Simon Riggs | 2006-06-20 09:06:41 | Re: Generic Monitoring Framework Proposal |