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: | 28019.1290991343@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 | Content-Type | Size |
---|---|---|
simplify-index-pathkeys-2.patch | text/x-patch | 40.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-11-29 00:42:28 | Re: Report: Linux huge pages with Postgres |
Previous Message | Tom Lane | 2010-11-29 00:34:34 | Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements. |