Re: Misleading comment in tuplesort_set_bound - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Misleading comment in tuplesort_set_bound
Date
Msg-id 25719.1566856281@sss.pgh.pa.us
Whole thread Raw
In response to Misleading comment in tuplesort_set_bound  (James Coleman <jtc331@gmail.com>)
Responses Re: Misleading comment in tuplesort_set_bound  (Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>)
List pgsql-hackers
James Coleman <jtc331@gmail.com> writes:
> While digging into the incremental sort patch, I noticed in
> tuplesort.c at the beginning of the function in $SUBJECT we have this
> comment and assertion:

> tuplesort_set_bound(Tuplesortstate *state, int64 bound)
> {
>     /* Assert we're called before loading any tuples */
>     Assert(state->status == TSS_INITIAL);

> But AFAICT from reading the code in puttuple_common the state remains
> TSS_INITIAL while tuples are inserted (unless we reach a point where
> we decide to transition it to TSS_BOUNDED or TSS_BUILDRUNS).

You missed the relevance of the next line:

    Assert(state->memtupcount == 0);

I think the comment is fine as-is.  Perhaps the code would be clearer
though, if we merged those two asserts into one?

    /* Assert we're called before loading any tuples */
    Assert(state->status == TSS_INITIAL &&
           state->memtupcount == 0);

I'm not totally sure about the usefulness/relevance of the two
assertions following these, but they could likely do with their
own comment(s), because this one surely isn't covering them.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: old_snapshot_threshold vs indexes
Next
From: Peter Geoghegan
Date:
Subject: IoT/sensor data and B-Tree page splits