Re: WIP: [[Parallel] Shared] Hash

On Mon, Mar 27, 2017 at 11:03 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> >> Is there a risk that this ends up
running afoul of filename length
>> limits on some platforms?
>
> Hmm. I didn't think so. Do we have a project guideline on maximum
> path lengths based on some kind of survey? There are various limits
> involved (filesystem and OS per-path-component limits, total limits,
> and the confusing PATH_MAX, MAX_PATH etc macros), but I was under the
> impression that these numbers were always at least 255. This scheme
> seems capable of producing ~50 bytes in the final component
> (admittedly more if int is 64 bits), and then nowhere near enough to
> reach a limit of that order in the earlier components.

Err, plus prefix. Still seems unlikely to be too long.

>> I'm a bit unhappy with the partition terminology around this. It's
>> getting a bit confusing. We have partitions, participants and
>> segements. Most of them could be understood for something entirely
>> different than the meaning you have here...
>
> Ok. Let me try to explain and defend them and see if we can come up
> with something better.
>
> 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.

--
Thomas Munro
http://www.enterprisedb.com