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

Re: knngist patch support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, tomas(at)tuxteam(dot)de, "Ragi Y(dot) Burhum" <rburhum(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: knngist patch support
Date: 2010-02-13 18:28:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> I see your point. May be it's better to introduce new system table? pg_amorderop 
> to store ordering operations for index.

We could, but that approach doesn't scale to wanting more categories
in the future --- you're essentially decreeing that every new category
of opclass-associated operator will require a new system catalog,
along with all the infrastructure needed for that.  That guarantees
that the temptation to take shortcuts will remain high.

If we didn't already have the plus/minus-for-WINDOW-RANGE example
staring us in the face, I might think that an extensible solution
wasn't needed here ... but we do so I think we really need to allow
for multiple categories in some form.

Now on the flip side, adding new catalogs would allow flexibility to
add columns that aren't there in pg_amop, which could come in handy
if some future category requires auxiliary data that's not needed for
the existing category of index search operators.  But since the two
examples we have at hand don't appear to need any extra data, this
argument isn't real strong.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-13 18:31:44
Subject: Re: knngist patch support
Previous:From: Greg StarkDate: 2010-02-13 18:17:15
Subject: Re: Streaming Replication docs

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