Re: knngist - 0.8

From: David Fetter <david(at)fetter(dot)org>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, teodor(at)sigaev(dot)ru, pgsql-hackers(at)postgresql(dot)org
Subject: Re: knngist - 0.8
Date: 2010-08-09 23:46:19
Message-ID: 20100809234619.GA11024@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 09, 2010 at 06:35:47PM -0300, Euler Taveira de Oliveira wrote:
> Alexander Korotkov escreveu:
> > Such approach can give benefit when we need to filter by
> > similarity. For example, in pg_trgm "%" is used for similarity
> > filtering, but similarity threshold is global for session. That's
> > why we can't create complex queries which contain similarity
> > filtering with different threshold.
> >
> What do you mean by complex queries? You can always use the SET
> command. Sadly it doesn't work when you have different thresholds
> within distinct subqueries. (In pg_similarity I use this approach
> to set the function's thresholds). What I am investigating is a way
> to build an index with some user-defined parameters. (We already
> have some infra-structure in reloptions for that but it needs some
> work to support my idea). I have some half-baked patch that I'm
> planning to submit to some of the CFs. Unfortunately, I don't have
> time for it ATM.

Do you have enough of it to send out as WIP?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-08-10 00:30:40 RecordTransactionCommit() and SharedInvalidationMessages
Previous Message Robert Haas 2010-08-09 23:39:39 Re: security label support, part.2