From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changes in amcanreturn() interface to support multicolumn indexes |
Date: | 2014-06-26 17:55:24 |
Message-ID: | 42401.1403805324@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com> writes:
> There is a question of support multicolumn index only scans for GIST.
> gistcanreturn() can return true if fetch is implemented for all indexed
> columns and false otherwise.
> But that's not very good case for multicolumn indexes.
> I think, it requires extend the interface to add separate columns checking.
> But I can't understand what kind of changes is required
> and how would it affect on previous amcanreturn interface.
Yeah, rather than just returning a bool, I suppose we need it to return
an indication of which index columns it's prepared to return values for.
(And then I guess the runtime API should return nulls for index columns
it can't handle.) You could probably use either a bitmapset or an integer
List to return the column numbers.
I wouldn't be too worried about backwards compatibility in changing that
API. If there are any people supporting outside-core index AMs, they've
got much bigger problems than this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sawada Masahiko | 2014-06-26 17:57:45 | Re: Set new system identifier using pg_resetxlog |
Previous Message | Vik Fearing | 2014-06-26 17:19:57 | Re: SQL access to database attributes |