On Fri, Oct 9, 2015 at 5:54 PM, Robert Haas <robertmh...@gmail.com> wrote: > I think that is true. I spent some time thinking about whether the > way you used INT_MIN as a sentinel value should be changed around > somehow, but ultimately I decided that it wasn't too bad and that > suggesting something else would be pointless kibitzing. I also tried > to think of scenarios in which this would lose, and I'm not totally > convinced that there aren't any, but I'm convinced that, if they > exist, I don't know what they are. Since the patch did deliver a > small improvement on my test cases and on yours, I think we might as > well have it in the tree. If some pathological scenario shows up > where it turns out to hurt, we can always fix it then, or revert if it > need be.
That seems very reasonable. I noticed that there is still one comment that I really should have removed as part of this work. The comment didn't actually add any new information for 9.5, but is now obsolete. Attached patch removes it entirely. -- Peter Geoghegan
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c index d545c34..3978b1e 100644 --- a/src/backend/utils/adt/varlena.c +++ b/src/backend/utils/adt/varlena.c @@ -2056,10 +2056,6 @@ bttext_abbrev_convert(Datum original, SortSupport ssup) int len; uint32 hash; - /* - * Abbreviated key representation is a pass-by-value Datum that is treated - * as a char array by the specialized comparator bttextcmp_abbrev(). - */ pres = (char *) &res; /* memset(), so any non-overwritten bytes are NUL */ memset(pres, 0, sizeof(Datum));
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
