Re: Strange assertion using VACOPT_FREEZE in vacuum.c

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Strange assertion using VACOPT_FREEZE in vacuum.c
Дата
Msg-id 5500B20C.9010509@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Strange assertion using VACOPT_FREEZE in vacuum.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 3/11/15 3:57 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> But autovacuum is still manufacturing a VacuumStmt by hand.  If we want
>> to get rid of that, I think it'd work to have a new
>> ExecVacuum(VacuumStmt, params) function which is called from
>> standard_ProcessUtility and does just vacuum(rel, relid, params).
>> Autovacuum on the other hand can call vacuum() without having to
>> construct the parse node.
>
> Why would we want to get rid of that?  A struct is a handy and legible
> way to pass a pile of parameters.  I doubt it would be an improvement for
> vacuum() to grow a long list of separate parameters.

We're not exactly getting rid of it; Thomas' patch adds a second struct 
that deals with detailed vacuum parameters that are not actually present 
in VacuumStmt. These are things that are specific to autovac but not 
manual VACUUM. But the patch in it's current form still have autovac 
building a somewhat bogus VacuumStmt.

What's being proposed is to expose VacuumStmt (which only makes sense 
for VACUUM) only where it's needed, and use VacuumParams everywhere 
else. In particular, this means autovac will just deal with VacuumParams 
and will no longer build a fake VacuumStmt.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: improve pgbench syntax error messages
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Precedence of standard comparison operators