| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Strange assertion using VACOPT_FREEZE in vacuum.c |
| Date: | 2015-03-11 20:57:42 |
| Message-ID: | 10208.1426107462@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-03-11 21:14:20 | Re: proposal: searching in array function - array_position |
| Previous Message | Tom Lane | 2015-03-11 20:53:43 | Re: using CustomScan to inject nodes into the plan |