Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processingBRIN indexes in VACUUM
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processingBRIN indexes in VACUUM |
Дата | |
Msg-id | 20171103162825.oc57nue7z257qugo@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processingBRIN indexes in VACUUM
|
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > Tom Lane wrote: > >> Do we still need the complication in brinsummarize to discriminate > >> against the last partial range? Now that the lock consideration > >> is gone, I think that might be a wart. > > > In the case of VACUUM, it's not desirable to create a summarization for > > the last partial range, because if the table is still being filled, that > > would slow down the insertion process. > > Hm. Okay, but you should change the comment then, because "we do not want > to spend one RelationGetNumberOfBlocks call" is a pretty weak reason. Changed. > Also, I think I would accept that argument for autovacuum, but maybe > not so much for a manual vacuum. Maybe you should drive it off > IsAutovacuumWorker rather than which operation is being done. I think your argument is sensible for some uses (where people run manual VACUUM after loading data) but not others (where people just use manual VACUUM in place of autovacuuming -- because they don't trust autovac, or the schedule isn't convenient, or whatever other reason). I've seen both things being done in production. If we do as you suggest, there is no way to do the manual vacuum without summarizing the partial also; the approach of doing the partial only in brin_summarize_new_values lets the user choose what to do. Once upon a time I thought about adding a reloption to let the user choose what to do, but I never got around to writing a patch. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: