From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Making strxfrm() blobs in indexes work |
Date: | 2014-02-12 23:30:16 |
Message-ID: | 20140212233016.GD15462@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 02, 2014 at 05:09:06PM -0800, Peter Geoghegan wrote:
> However, it also occurs to me that strxfrm() blobs have another useful
> property: We (as, say, the author of an equality operator on text, an
> operator intended for a btree operator class) *can* trust a strcmp()'s
> result on blobs, provided the result isn't 0/equal, *even if the blobs
> are truncated*. So maybe a better scheme, and certainly a simpler one
> would be to have a pseudo-attribute in inner pages only with, say, the
> first 8 bytes of a strxfrm() blob formed from the logically-leading
> text attribute of the same indexTuple. Because we're only doing this
> on inner pages, there is a very good chance that that will be good
> enough most of the time. This also allows us to reduce bloat very
> effectively.
(A bit late to the party). This idea has come up before and the most
annoying thing is that braindead strxfrm api. Namely, to strxfrm a
large strings you need to strxfrm it completely even if you only want
the first 8 bytes.
That said, since btree index tuples are limited to <3k anyway, the
overhead probably isn't that bad.
I think it would make a noticable difference if it can be made to work.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
-- Arthur Schopenhauer
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2014-02-12 23:30:55 | Re: contrib/cache_scan (Re: What's needed for cache-only table scan?) |
Previous Message | Craig Ringer | 2014-02-12 23:22:17 | Re: narwhal and PGDLLIMPORT |