Skip site navigation (1) Skip section navigation (2)

Re: To all the pgsql developers..Have a look at the operators proposed by me in my research paper.

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Jim Nasby <decibel(at)decibel(dot)org>, Tasneem Memon <tasneememon(at)hotmail(dot)com>
Subject: Re: To all the pgsql developers..Have a look at the operators proposed by me in my research paper.
Date: 2007-06-02 17:33:06
Message-ID: 200706021033.06428.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tasneem,

> > The margins to the op2, i.e. m1 and m2, are added dynamically on  
> > both the sides, considering the value it contains. To keep this  
> > margin big is important for a certain reason discussed later.
> > The NEAR operator is supposed to obtain the values near to the op2,  
> > thus the target membership degree(md) is initially set to 0.8.
> > The algorithm compares the op1(column) values row by row to the  
> > elements of the set that NEAR defined, i.e. the values from md 1.0  
> > to 0.8, adding matching tuples to the result set.

Are we talking about a mathematical calculation on the values, or an algorithm 
against the population of the result set?  I'm presuming the latter or you 
could just use a function.  If so, is NEAR an absolute range or based on 
something logarithmic like standard deviation?

Beyond that, I would think that this mechanism would need some kind of extra 
heuristics to be at all performant, otherwise you're querying the entire 
table (or at least the entire index) every time you run a query.  Have you 
given any thought to this?

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

In response to

pgsql-hackers by date

Next:From: George PavlovDate: 2007-06-02 18:32:57
Subject: Re: query log corrupted-looking entries
Previous:From: Tasneem MemonDate: 2007-06-02 13:37:19
Subject: Re: To all the pgsql developers..Have a look at the operators proposed by me in my researc

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group