Horton

Re: index-only scans

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-10-11T20:44:40Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reduce the alignment requirement of type "name" from int to char, and arrange

On Wed, Oct 12, 2011 at 12:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Hm.  I had been supposing that lossless compress functions would just be
> no-ops.  If that's not necessarily the case then we might need something
> different from the opclass's decompress function to get back the
> original data.  However, that doesn't really solve the problem I'm
> concerned about, because the existence and use of such a function would
> be entirely internal to GiST.  There still needs to be a way for the
> planner to know which opclasses support data retrieval.  And I do *not*
> want to see us hard-wire "the presence of opclass function 8 means a
> GiST opclass can return data" into the planner.
>
> Maybe, instead of a simple constant amcanreturn column, we need an AM
> API function that says whether the index can return data.
>
I like idea of such AM API function. Since single multicolumn index can use
multiple opclasses, AM API function should also say *what* data index can
return.

------
With best regards,
Alexander Korotkov.