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

Re: Rethinking representation of sort/hash semantics in queries and plans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rethinking representation of sort/hash semantics in queries and plans
Date: 2010-11-29 00:42:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I wrote:
> Now, this loss of flexibility doesn't particularly bother me, because
> I know of no existing or contemplated btree-substitute access methods.
> If one did appear on the horizon, there are a couple of ways we could
> fix the problem, the cleanest being to let a non-btree opfamily declare
> that it sorts the same as btree opfamily so-and-so.  Or we could fix
> it locally in plancat.c by performing the lookup-the-operators-and-
> then-the-btree-opfamilies dance on the fly when setting up IndexOptInfo
> for a non-btree amcanorder index.  But I'm disinclined to write such
> code when there's no way to test it and no foreseeable possibility
> that it'll ever be used.  Maybe we should just make plancat.c throw
> a not-implemented error if amcanorder is true but it's not btree.

On further reflection the last seems like clearly the thing to do.

> PS: the attached patch doesn't yet include removal of relcache
> rd_operator arrays, since that would just make the patch bigger
> without exposing any new issues.

And here's the complete patch.

			regards, tom lane

Attachment: simplify-index-pathkeys-2.patch
Description: text/x-patch (40.6 KB)

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-11-29 00:42:28
Subject: Re: Report: Linux huge pages with Postgres
Previous:From: Tom LaneDate: 2010-11-29 00:34:34
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.

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