Re: sync_file_range()
От | Zeugswetter Andreas DCP SD |
---|---|
Тема | Re: sync_file_range() |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA5790116C40C@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | sync_file_range() (Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>) |
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: