| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Pete Stevenson <etep(dot)nosnevets(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: MVCC overheads |
| Date: | 2016-07-08 18:44:44 |
| Message-ID: | 21628.1468003484@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> VACUUM in itself is an offloading optimization; the whole point of it
>> is to do maintenance in a background process not foreground queries.
> Well, if VACUUM worked so great, we wouldn't get so many trouble reports
> with it. There's substantial improvement we could make in that area.
Sure, and we've been chipping away at that problem over time, including
some significant improvement in 9.6. My point is just that it's a good
idea to understand VACUUM as being some pre-existing work that's related
to this offloading idea.
> Sure, but we could *also* do it separately, splitting VACUUMs tasks of
> tuple freezing, page compaction, and index entry removal each into
> separate tasks.
Uh ... wouldn't that tend to make things worse? The knocks on VACUUM are
too much I/O and too much latency for cleanup, and I can't see how
splitting it does anything good on either score.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2016-07-08 18:45:57 | Re: MVCC overheads |
| Previous Message | Alvaro Herrera | 2016-07-08 18:42:20 | Re: [BUG] pg_basebackup from disconnected standby fails |