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 <br...@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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers