On Wed, Jan 11, 2017 at 12:24:55PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Therefore, I think we need WARM done first, then we can test indirect
> > indexes to see if they are a sufficient win to add it for the small
> > percentage of users who will use it.
>
> Agreed -- that's my plan.
Thanks. I hate to pour cold water on a feature, honestly, but I don't
want us to over-react to the write amplification problem either. We
don't want to have X features to improve it when a single feature is
sufficient. (Amit might be right that the real win for indirect indexes
will be some type of clustered index, where the win might be larger.)
I know Uber dumped us "allegedly" over this issue (among other
complaints), but I am concerned we are overreacting if we change
Postgres too much to address this concern. Hence, I am arguing we don't
add both features at the same time without evaluating the need for the
second feature after the first feature is done.
Let me give an example of us not over-reacting. When we implemented HOT
(thanks Pavan), we considered the problem that our default fill factor
for heap is 100%, so there is no room for HOT updates on a full page.
Should we reduce the default fill factor when adding HOT? We decided
not to, on the hope that the first update to a row on a full page would
put the new row on a page with sufficient free space for future HOT
updates, and that has proven to be the case.
We do document lower full factors for heap to improve HOT updates, but I
think everyone feels that is mostly for good performance after the
initial table load, and that over time the frequently-updated rows will
naturally migrate to pages with sufficient free space.
My point is that we didn't over-react in that case, and the result was
fine --- read-only rows got dense storage, and frequently-updated rows
got sufficient free space for HOT, but we had to push HOT into
production to confirm we were in good shape. I am thinking we need to
complete WARM to figure out what it doesn't do well in production so we
can fairly evaluate 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 +