From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Subject: | Re: WARM and indirect indexes |
Date: | 2017-02-23 00:48:07 |
Message-ID: | 20170223004807.GE20486@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 11, 2017 at 04:38:10PM -0500, Robert Haas wrote:
> More broadly, I don't share Bruce's negativity about indirect indexes.
> My estimate of what needs to be done for them to be really useful is -
> I think - higher than your estimate of what needs to be done, but I
> think the concept is great. I also think that some of the concepts -
> like allowing the tuple pointers to have widths other than 6 byes -
> could turn out to be a good foundation for global indexes in the
> future. In fact, it might be considerably easier to make an indirect
> index span a partitioning hierarchy than it would be to do the same
> for a regular index. But regardless of that, the feature is good for
> what it offers today.
I am worried that indirect indexes might have such limited usefulness
with a well-designed WARM feature that the syntax/feature would be
useless for 99% of users. In talking to Alexander Korotkov, he
mentioned that indirect indexes could be used for global/cross-partition
indexes, and for index-organized tables (heap and index together in a
single file). This would greatly expand the usefulness of indirect
indexes and would be exciting.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-02-23 02:37:17 | Re: PATCH: Batch/pipelining support for libpq |
Previous Message | Petr Jelinek | 2017-02-23 00:41:06 | Re: Logical replication existing data copy |