From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Blake Smith <blakesmith0(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hstore: Query speedups with Gin index |
Date: | 2013-08-28 17:40:13 |
Message-ID: | 20130828174013.GA32052@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-08-28 13:31:22 -0400, Bruce Momjian wrote:
> On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
> > Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> > > On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith <blakesmith0(at)gmail(dot)com> wrote:
> > >> The combined entry is used to support "contains (@>)" queries, and the key
> > >> only item is used to support "key contains (?)" queries. This change seems
> > >> to help especially with hstore keys that have high cardinalities. Downsides
> > >> of this change is that it requires an index rebuild, and the index will be
> > >> larger in size.
> >
> > > Index rebuild would be a problem only for minor releases,
> >
> > That's completely false; people have expected major releases to be
> > on-disk-compatible for several years now. While there probably will be
> > future releases in which we are willing to break storage compatibility,
> > a contrib module doesn't get to dictate that.
> >
> > What might be a practical solution, especially if this isn't always a
> > win (which seems likely given the index-bloat risk), is to make hstore
> > offer two different GIN index opclasses, one that works the traditional
> > way and one that works this way.
> >
> > Another thing that needs to be taken into account here is Oleg and
> > Teodor's in-progress work on extending hstore:
> > https://www.pgcon.org/2013/schedule/events/518.en.html
> > I'm not sure if this patch would conflict with that at all, but it
> > needs to be considered.
>
> We can disallow in-place upgrades for clusters that use certain contrib
> modules --- we have done that in the past.
But that really cannot be acceptable for hstore. The probably most
widely used extension there is.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-08-28 18:04:59 | Re: dynamic background workers, round two |
Previous Message | Bruce Momjian | 2013-08-28 17:31:22 | Re: Hstore: Query speedups with Gin index |