On Fri, Mar 24, 2017 at 12:25 AM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > > > On Thu, Mar 23, 2017 at 7:53 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: >> >> > >> >> I am not sure on what basis user can set such parameters, it will be >> quite difficult to tune those parameters. I think the point is >> whatever threshold we keep, once that is crossed, it will perform two >> scans for all the indexes. > > > Well, that applies to even vacuum parameters, no? >
I don't know how much we can directly compare the usability of the new parameters you are proposing here to existing parameters. > The general sense I've got > here is that we're ok to push some work in background if it helps the > real-time queries, and I kinda agree with that. > I don't think we can define this work as "some" work, it can be a lot of work depending on the number of indexes. Also, I think for some cases it will generate maintenance work without generating benefit. For example, when there is one index on a table and there are updates for that index column. > Having said that, I see many ways we can improve on this later. Like we can > track somewhere else information about tuples which may have received WARM > updates (I think it will need to be a per-index bitmap or so) and use that > to do WARM chain conversion in a single index pass. > Sure, if we have some way to do it in a single pass or does most of the time in foreground process (like we have some dead marking idea for indexes), then it would have been better. > But this is clearly not > PG 10 material. > I don't see much discussion about this aspect of the patch, so not sure if it is acceptable to increase the cost of vacuum. Now, I don't know if your idea of GUC's make it such that the additional cost will occur seldom and this additional pass has a minimal impact which will make it acceptable. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
