[ thinks a bit ... ] At least for GIST, it is possible that whether
data can be regurgitated will vary depending on the selected opclass.
Some opclasses use the STORAGE modifier and some don't. I am not sure
how hard we want to work to support flexibility there. Would it be
sufficient to hard-c
On Mon, Jul 13, 2009 at 11:32 AM, Heikki
Linnakangas wrote:
> Tom Lane wrote:
>> One thought here is that an AM call isn't really free, and doing two of
>> them instead of one mightn't be such a good idea. I would suggest
>> either having a separate AM entry point to get both bits of data
>> ("amg
Tom Lane wrote:
> One thought here is that an AM call isn't really free, and doing two of
> them instead of one mightn't be such a good idea. I would suggest
> either having a separate AM entry point to get both bits of data
> ("amgettupledata"?) or adding an optional parameter to amgettuple.
I'm
Heikki Linnakangas writes:
> Tom Lane wrote:
>> What are you going to do for index types that don't store the original
>> data (e.g. hash)?
> They will obviously not be able to regurgitate index tuples. I have not
> yet decided how that's going to be signaled.
Well, I think that's a pretty criti
Tom Lane wrote:
> Heikki Linnakangas writes:
>> At the moment, amgettuple only returns pointers to heap tuples. There is
>> no way to return data from the index tuples. That needs to be changed to
>> support index-only scans.
>
> What are you going to do for index types that don't store the origi
Heikki Linnakangas writes:
> At the moment, amgettuple only returns pointers to heap tuples. There is
> no way to return data from the index tuples. That needs to be changed to
> support index-only scans.
What are you going to do for index types that don't store the original
data (e.g. hash)?
On Mon, Jul 13, 2009 at 8:19 AM, Heikki
Linnakangas wrote:
>
> I propose that we split index_getnext into two steps: fetching the next
> match from the index (index_next()), and fetching the corresponding heap
> tuple (index_fetch()).
A pretty trivial concern, but it seems confusing that the funct
At the moment, amgettuple only returns pointers to heap tuples. There is
no way to return data from the index tuples. That needs to be changed to
support index-only scans.
I propose that we split index_getnext into two steps: fetching the next
match from the index (index_next()), and fetching the
