From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "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 14:21:57 |
Message-ID: | E1539E0ED7043848906A8FF995BDA5790116C40C@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > 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.
>
> Well, some people would find those arguments compelling and
> some wouldn't. We already have a manually configurable
> RELSEG_SIZE, so people who want a 32Gb or whatever segment
> size can have it.
> But if you're dealing with terabyte-sized tables that's still
> a lot of segments.
>
> What I'd be inclined to do is allow people to set RELSEG_SIZE
> = 0 in pg_config_manual.h to select the unsegmented option.
> That way we already have the infrastructure in pg_control etc
> to ensure that the database layout matches the backend.
That sounds perfect. Still leaves the question of what to default to ?
Another issue is, that we would probably need to detect large file
support of the underlying filesystem, else we might fail at runtime :-(
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-20 14:34:13 | Re: Generic Monitoring Framework Proposal |
Previous Message | Greg Stark | 2006-06-20 14:19:37 | Re: Generic Monitoring Framework Proposal |