Re: GiST index performance

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: GiST index performance
Date: 2010-03-16 01:58:57
Message-ID: 603c8f071003151858o4d73d856n3a2d6a1d9a7da03@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Mar 15, 2010 at 11:58 AM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
> On Thu, 25 Feb 2010, Bruce Momjian wrote:
>>
>> Was there every any conclusion on this issue?
>
> Not really. Comments inline:
>
>> Matthew Wakeling wrote:
>>>
>>> Revisiting the thread a month back or so, I'm still investigating
>>> performance problems with GiST indexes in Postgres.
>>>
>>> Looking at http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items I'd
>>> like to clarify the contrib/seg issue. Contrib/seg is vulnerable to
>>> pathological behaviour which is fixed by my second patch, which can be
>>> viewed as complete. Contrib/cube, being multi-dimensional, is not
>>> affected
>>> to any significant degree, so should not need alteration.
>
> This issue is addressed by my patch, which AFAIK noone has reviewed.
> However, that patch was derived from a patch that I applied to bioseg, which
> is itself a derivative of seg. This patch works very well indeed, and gave
> an approximate 100 times speed improvement in the one test I ran.
>
> So you could say that the sister patch of the one I submitted is tried and
> tested in production.

We rely fairly heavily on the commitfest app to track which patches
need review; perhaps it would be good to add it here.

https://commitfest.postgresql.org/action/commitfest_view/open

I seem to recall thinking that this patch wasn't ready to apply for
some reason, but I'm not sure why I thought that.

...Robert

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dave Crooke 2010-03-16 03:04:45 Re: pg_dump far too slow
Previous Message Robert Haas 2010-03-16 01:53:10 Re: pg_dump far too slow