Re: Re: Abbreviated keys for Datum tuplesort - Mailing list pgsql-hackers
From | Andrew Gierth |
---|---|
Subject | Re: Re: Abbreviated keys for Datum tuplesort |
Date | |
Msg-id | 87wq2knxf2.fsf@news-spur.riddles.org.uk Whole thread Raw |
In response to | Re: Re: Abbreviated keys for Datum tuplesort (Peter Geoghegan <pg@heroku.com>) |
Responses |
Re: Re: Abbreviated keys for Datum tuplesort
|
List | pgsql-hackers |
>>>>> "Peter" == Peter Geoghegan <pg@heroku.com> writes: Peter> I attach a slightly tweaked version of Andrew's original. You changed this: static intcomparetup_datum(const SortTuple *a, const SortTuple *b, Tuplesortstate *state){ - int compare; + int32 compare; compare = ApplySortComparator(a->datum1, a->isnull1, Since ApplySortComparator returns int, and "compare" is used to store the return value of comparetup_datum which is also declared int, this seems inappropriate even as a "stylistic tweak". Also, your changes to the block comment for SortTuple now hide the fact that datum1 is potentially the abbreviated value in tuple as well as single-Datum cases. Here are the versions for comparison (mine is first): *************** *** 136,175 **** /* * The objects we actually sort are SortTuple structs. These contain * a pointer to the tuple proper(might be a MinimalTuple or IndexTuple), * which is a separate palloc chunk --- we assume it is just one chunk and * can be freed by a simple pfree(). SortTuples also contain the tuple's * first key column in Datum/nullflag format,and an index integer. * * Storing the first key column lets us save heap_getattr or index_getattr * calls duringtuple comparisons. We could extract and save all the key * columns not just the first, but this would increase codecomplexity and * overhead, and wouldn't actually save any comparison cycles in the common * case where the first keydetermines the comparison result. Note that * for a pass-by-reference datatype, datum1 points into the "tuple" storage. * - * There is one special case: when the sort support infrastructure provides an - * "abbreviated key" representation, where the key is (typically) a pass by - * value proxy for a pass by reference type. In this case, the abbreviated key - * is stored in datum1 in place of the actual first key column. - * * When sorting single Datums, the data value is represented directly by ! * datum1/isnull1 for pass by value types (or null values). If the datatype is ! * pass-by-reference and isnull1 is false, then "tuple" points to a separately ! * palloc'd data value, otherwise "tuple" is NULL. The value of datum1 is then ! * either the same pointer as "tuple", or is an abbreviated key value as ! * described above. Accordingly, "tuple" is always used in preference to ! * datum1 as the authoritative value for pass-by-reference cases. * * While building initial runs, tupindex holds thetuple's run number. During * merge passes, we re-use it to hold the input tape number that each tuple in * the heapwas read from, or to hold the index of the next tuple pre-read * from the same tape in the case of pre-read entries. tupindex goes unused * if the sort occurs entirely in memory. */ typedef struct { void *tuple; /* the tuple proper */ Datum datum1; /* value of first key column */ bool isnull1; /* is first key column NULL? */ int tupindex; /* see notes above */ } SortTuple; --- 136,170 ---- /* * The objects we actually sort are SortTuple structs. These contain * a pointer to the tuple proper(might be a MinimalTuple or IndexTuple), * which is a separate palloc chunk --- we assume it is just one chunk and * can be freed by a simple pfree(). SortTuples also contain the tuple's * first key column in Datum/nullflag format,and an index integer. * * Storing the first key column lets us save heap_getattr or index_getattr * calls duringtuple comparisons. We could extract and save all the key * columns not just the first, but this would increase codecomplexity and * overhead, and wouldn't actually save any comparison cycles in the common * case where the first keydetermines the comparison result. Note that * for a pass-by-reference datatype, datum1 points into the "tuple" storage. * * When sorting single Datums, the data value is represented directly by ! * datum1/isnull1. If the datatype is pass-by-reference and isnull1 is false, ! * then datum1 points to a separately palloc'd data value that is also pointed ! * to by the "tuple" pointer; otherwise "tuple" is NULL. There is one special ! * case: when the sort support infrastructure provides an "abbreviated key" ! * representation, where the key is (typically) a pass by value proxy for a ! * pass by reference type. * * While building initial runs, tupindex holds the tuple's run number. During * merge passes,we re-use it to hold the input tape number that each tuple in * the heap was read from, or to hold the index of thenext tuple pre-read * from the same tape in the case of pre-read entries. tupindex goes unused * if the sort occursentirely in memory. */ typedef struct { void *tuple; /* the tuple proper */ Datum datum1; /* value of first key column */ bool isnull1; /* is first key column NULL? */ int tupindex; /* see notes above */ } SortTuple; -- Andrew (irc:RhodiumToad)
pgsql-hackers by date: