On Wed, Jan 11, 2017 at 12:36:24PM +0530, Pavan Deolasee wrote:
> That could also be seen as an advantage to indirect indexes. While I haven't
> seen the code, I believe indirect index code will only be hit if someone
> actually uses them. So there won't be any overhead for other users who do not
> wish to use the feature. WARM on the other hand will be "always on" feature,
> even for system tables. That clearly has advantages, both from usability
> perspective as well as the fact that the code will be heavily tested. But if
> there are cases which get adversely affected by WARM, they will have to pay the
> price for larger benefit.
>
> To me, a better strategy is probably to focus on one of the patches, get that
> in and then evaluate the second patch, both from complexity as well as
> performance given that the first patch may have narrowed the gaps.
Yes, that is exactly what I suggested in a post I just sent to this
thread. With WARM always-on, it seems like the best thing to do first
because everyone will use it silently, and we can then decide if a user
controlled feature is warranted, and under what circumstances we should
recommend the user of the feature.
However, I am concerned that doing the two features serially (not in
parallel) might mean that the second feature doesn't make it into
Postgres 10, but considering we will live with this feature probably
forever, I think it is the best course.
-- 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 +