Re: sync_file_range() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: sync_file_range()
Date
Msg-id 27568.1150811946@sss.pgh.pa.us
Whole thread Raw
In response to Re: sync_file_range()  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
"Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sync_file_range()
Next
From: Greg Stark
Date:
Subject: Re: shall we have a TRACE_MEMORY mode