Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: David E. WheelerDate: 2011-04-28 21:49:36
Subject: Explain Nodes
Previous:From: Tom LaneDate: 2011-04-28 21:27:29
Subject: Re: Extreme bloating of intarray GiST indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group