From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: index-only scans |
Date: | 2011-10-11 13:22:20 |
Message-ID: | 25687.1318339340@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Have you given any thought to what would be required to support
> index-only scans on non-btree indexes - particularly, GIST? ISTM we
> might have had a thought that some GIST opclasses but not others would
> be able to regurgitate tuples, or maybe even that it might vary from
> index tuple to index tuple. But that discussion was a long time ago,
> and my memory is fuzzy.
It would have to be a per-opclass property, for sure, since the basic
criterion is whether the opclass's "compress" function is lossy.
I don't think we can tolerate a situation where some of the index tuples
might be able to yield data and others not --- that would undo all the
improvements I've been working on over the past few days.
I haven't thought as far ahead as how we might get the information
needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
CLASS might be the only way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2011-10-11 13:28:30 | Re: Range Types - typo + NULL string constructor |
Previous Message | Florian Pflug | 2011-10-11 13:20:05 | Re: Range Types - typo + NULL string constructor |