From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extreme bloating of intarray GiST indexes |
Date: | 2011-04-28 21:41:40 |
Message-ID: | BANLkTinpTkkkgWeUGtW4kYevMP-wHUM=VQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 29, 2011 at 1:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I seem to recall some discussion recently about documenting where you
> should cut over to using "gist__intbig_ops" --- IIRC, it wasn't all that
> "big" by modern standards. But it doesn't look like any such change made
> it into the docs. Should we reopen that discussion?
>
Actually, I don't see a reason to make decision between gist__int_ops
and gist__intbig_ops. Because we can choose between full enumeration and
lossy bitmap on the fly on the base of array length (when some length
threshold achived array is converted to bitmap). If this problem is urgent,
I can write a patch with opclass that would seem more suitable to be default
to me, when I'll have a time for it.
----
With best regards,
Alexander Korotkov.
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-04-28 21:49:36 | Explain Nodes |
Previous Message | Tom Lane | 2011-04-28 21:27:29 | Re: Extreme bloating of intarray GiST indexes |