Re: Faster inserts with mostly-monotonically increasing values
От | Andrew Dunstan |
---|---|
Тема | Re: Faster inserts with mostly-monotonically increasing values |
Дата | |
Msg-id | CAA8=A78M8k9SCEC9wRr8pZigxraEpCKaMyAv2uac6Zyh9SVvdQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Faster inserts with mostly-monotonically increasing values (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: Faster inserts with mostly-monotonically increasing values
|
Список | pgsql-hackers |
On Mon, Mar 26, 2018 at 6:06 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > > > On Sun, Mar 25, 2018 at 6:00 AM, Andrew Dunstan > <andrew.dunstan@2ndquadrant.com> wrote: >> >> On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee >> <pavan.deolasee@gmail.com> wrote: >> >> >> >> >> >> I would probably just have a few regression lines that should be sure >> >> to exercise the code path and leave it at that. >> >> >> > >> > I changed the regression tests to include a few more scenarios, >> > basically >> > using multi-column indexes in different ways and they querying rows by >> > ordering rows in different ways. I did not take away the vacuum and I >> > believe it will actually help the tests by introducing some fuzziness in >> > the >> > tests i.e. if the vacuum does not do its job, we might execute a >> > different >> > plan and ensure that the output remains unchanged. >> > >> >> >> If we're going to keep the vacuums in there, do we need to add a wait >> barrier like Claudio suggested upthread? >> > > I don't think we need the wait barrier since we're no longer printing the > explain plan. In the worst case, the vacuum may not get to set pages > all-visible, thus planner choosing something other than an index-only-scan, > but I guess that fuzziness actually helps the regression tests. That way we > get confirmation regarding the final result irrespective of the plan chosen. > Fair enough. Committed. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: