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
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 |