From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Indirect indexes
Date: Thu, 20 Oct 2016 10:04:37 -0400
Message-ID: <20161020140437.GA18972@momjian.us> (raw)
In-Reply-To: <20161020133923.bwduqwzc3vh2wb77@alvherre.pgsql>
References: <20161020122937.GA28621@momjian.us>
<20161020133923.bwduqwzc3vh2wb77@alvherre.pgsql>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Thu, Oct 20, 2016 at 10:39:23AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Just to clarify, if a feature improves performance by 1%, but is enabled
> > by default, that is 10x more useful across our entire user base as the
> > feature numbers listed above, 1% vs 0.1%.
>
> Great. But not all users are alike. We have big profile users that
> write blog posts that get echoed all over the world who would benefit
> from things that perhaps other users would not benefit that much from.
>
> > Also, it seems indirect indexes would be useful for indexing columns
> > that are not updated frequently on tables that are updated frequently,
> > and whose primary key is not updated frequently. That's quite a logic
> > problem for users to understand.
>
> I don't think we should be optimizing only for dumb users. In any case,
> updating primary key values is very rare; some would say it never
> happens.
Uh, so we are writing the database for sophisticated users who write
blog posts who make us look bad? Really?
My point is that we need to look at the entire user base, and look at
the adoption rates of features, and figure out how to maximize that.
You are right that sophisticated users can hit roadblocks, and we need
to give them a solution that keeps them on Postgres. However, if we can
solve the problem in a way that everyone benefits from by default (e.g.
WARM), why not implement that instead, or at least go as far as we can
with that before adding a feature that only sophisticated users will
know to enable. (My "logic problem" above shows that only sophisticated
users will likely use indirect indexes.)
If we have to solve a vacuum problem with indirect indexes, and WARM
also is limited by the same vacuum problem, let's fix the vacuum problem
for WARM, which will be used by all users.
In summary, I need to know what problems indirect indexes fix that WARM
cannot, or eventually cannot if given the amount of engineering work we
would need to implement indirect indexes.
--
Bruce Momjian <bruce@momjian.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 +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, alvherre@2ndquadrant.com, simon@2ndquadrant.com, pavan.deolasee@gmail.com, a.korotkov@postgrespro.ru, robertmhaas@gmail.com
Subject: Re: Indirect indexes
In-Reply-To: <20161020140437.GA18972@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox