Re: sync_file_range()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
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 13:59:06
Message-ID: 27568.1150811946@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-06-20 14:11:20 Re: shall we have a TRACE_MEMORY mode
Previous Message Tom Lane 2006-06-20 13:52:24 Re: sync_file_range()