Re: Extreme bloating of intarray GiST indexes

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.

In response to

Responses

Browse pgsql-hackers by date

  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