On 01/30/2017 07:45 PM, Peter Geoghegan wrote:
On Mon, Jan 30, 2017 at 4:04 AM, Heikki Linnakangas <hlinn...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
