Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)
Date
Msg-id 12919.1317441811@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> So what I'm thinking we ought to do is redefine things so that
> initGISTstate sets fn_mcxt to a context that has the same lifespan as
> the GISTSTATE itself does.  We could possibly eliminate a few retail
> pfree's in the process, eg by keeping the GISTSTATE itself in that same
> context.
> Having done that, what gtrgm_consistent is doing would be an officially
> supported (dare I suggest even documented?) thing instead of a kluge,
> and we could then adopt the same methodology in gtrgm_penalty.

I've committed patches along this line.  On my machine, the time needed
to do the test case Heikki proposed (build a gist_trgm_ops index on the
contents of /usr/share/dict/words) drops from around 29.9 seconds to
about 17.3.  makesign is now down in the noise according to oprofile,
so I see no further reason to pursue the patch that started this thread.

What's not in the noise is the memcmp() required to check if the cached
makesign result is still good --- as best I can tell, that's near 50%
of the remaining runtime.  I don't see any non-invasive way to avoid
that.  If we were willing to redo the GiST support function API, we
could fix it, but I'm not sure it's worth that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: pg_cancel_backend by non-superuser
Next
From: Tom Lane
Date:
Subject: Re: pg_cancel_backend by non-superuser