On Sun, Mar 26, 2017 at 3:41 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: >> 1. Segments are what buffile.c already calls the individual >> capped-at-1GB files that it manages. They are an implementation >> detail that is not part of buffile.c's user interface. There seems to >> be no reason to change that. > > After reading your next email I realised this is not quite true: > BufFileTell and BufFileSeek expose the existence of segments.
Yeah, that's something that tuplestore.c itself relies on. I always thought that the main reason practical why we have BufFile multiplex 1GB segments concerns use of temp_tablespaces, rather than considerations that matter only when using obsolete file systems: /* * We break BufFiles into gigabyte-sized segments, regardless of RELSEG_SIZE. * The reason is that we'd like large temporary BufFiles to be spread across * multiple tablespaces when available. */ Now, I tend to think that most installations that care about performance would be better off using RAID to stripe their one temp tablespace file system. But, I suppose this still makes sense when you have a number of file systems that happen to be available, and disk capacity is the main concern. PHJ uses one temp tablespace per worker, which I further suppose might not be as effective in balancing disk space usage. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
