On 01/30/2017 07:45 PM, Peter Geoghegan wrote:
> On Mon, Jan 30, 2017 at 4:04 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Alternatively, we could fix this with a small change in ltsWriteBlock(), see
>> attached patch. When we're about to create a hole in the file, write
>> all-zero blocks to avoid the creating hole, before the block itself. That's
>> not quite as efficient as writing the actual block contents into the hole,
>> which avoids having to write it later, but probably won't make any
>> measurable difference in practice. I'm inclined to do that, because it
>> relaxes the rules on what you're allowed to do, in what order, which makes
>> this more robust in general.
>
> Why write an all-zero block, rather than arbitrary garbage, which is
> all that BufFile really requires? I think it's because sizeof(int) nul
> bytes represent the end of a run for tuplesort's purposes. That makes
> me doubtful that this is any more robust or general than what I
> proposed. So, I don't have a problem with the performance implications
> of doing this, which should be minor, but I'm concerned that it
> appears to be more general than it actually is.
It won't make any difference for correctness what bit pattern you write
to "fill the hole", but you have to write something, and zeros seems
like a natural choice.
- Heikki
