Re: WIP: [[Parallel] Shared] Hash - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: WIP: [[Parallel] Shared] Hash
Date
Msg-id CAH2-Wz=CH59jxL-W67gaKzCM-ao8j3QWhjdf-iWPt9QCwWJ4tQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: [[Parallel] Shared] Hash  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Sun, Mar 26, 2017 at 3:41 PM, Thomas Munro
<thomas.munro@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
temporaryBufFiles 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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WIP: [[Parallel] Shared] Hash
Next
From: Pavel Stehule
Date:
Subject: Re: New CORRESPONDING clause design