Re: B-Tree support function number 3 (strxfrm() optimization)

On Thu, Sep 25, 2014 at 11:53 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I haven't looked at that part of the patch in detail yet, so... not
> really. But I don't see why you'd ever need to restart heap tuple
> copying. At most you'd need to re-extract datum1 from the tuples you
> have already copied.

Well, okay, technically it's not restarting heap tuple copying, but
it's about the same thing. The point is that you have to stream a
significant chunk of the memtuples array through memory again. Not to
mention, having infrastructure to do that, and pick up where we left
off, which is significantly more code, all to make comparetup_heap() a
bit clearer (i.e. making it so that it won't have to think about an
extra sortsupport state).

> To find out how much that optimization buys, you
> should use tuples with many variable-length columns (say, 50)
> preceding the text column you're sorting on. I won't be surprised if
> that turns out to be expensive enough to be worth worrying about, but
> I have not benchmarked it.

Sorry, but I don't follow. I don't think the pertinent question is if
it's a noticeable cost. I think the pertinent question is if it's
worth it. Doing something about it necessitates a lot of extra memory
access. Not doing something about it hardly affects the amount of
memory access required, perhaps not at all.

--
Peter Geoghegan