Re: Small GIN optimizations (after 9.4)

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Small GIN optimizations (after 9.4)
Date: 2014-02-11 23:30:21
Message-ID: CAPpHfdsxxqRNVNQpxxeH4anvgx3yC-1M7+97GN7UzzMXnKEv1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 12, 2014 at 2:58 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Sun, Feb 9, 2014 at 02:17:12PM +0400, Alexander Korotkov wrote:
> > On Thu, Feb 6, 2014 at 8:31 PM, PostgreSQL - Hans-J rgen Sch nig <
> > postgres(at)cybertec(dot)at> wrote:
> >
> > i think there is one more thing which would be really good in GIN
> and which
> > would solve a ton of issues.
> > atm GIN entries are sorted by item pointer.
> > if we could sort them by a "column" it would fix a couple of real
> work
> > issues such as ...
> >
> > SELECT ... FROM foo WHERE "tsearch_query" ORDER BY price
> DESC LIMIT
> > 10
> >
> > ... or so.
> > it many cases you want to search for a, say, product and find the
> cheapest
> > / most expensive one.
> > if the tsearch_query yields a high number of rows (which it often
> does) the
> > subsequent sort will kill you.
> >
> >
> > This is not intended to be a small change. However, some solution might
> be
> > possible in post 9.4 gin improvements or in new secret indexing project
> which
> > will be presented at PGCon :-)
>
> Would any of the listed changes cause backward-incompatible changes to
> the on-disk format, causing problems for pg_upgrade?
>

None of them.

------
With best regards,
Alexander Korotkov.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-02-11 23:30:52 Re: narwhal and PGDLLIMPORT
Previous Message Tom Lane 2014-02-11 23:22:26 Re: narwhal and PGDLLIMPORT