| 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: | Whole Thread | Raw Message | 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 |