| From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Visibility Groups |
| Date: | 2008-08-07 14:49:38 |
| Message-ID: | 603c8f070808070749w6e3ad9e8k384630bea8787167@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I think this would be a lot of mechanism and complication that will go
> completely unused in the field. It'll be impossible even to explain let
> alone to use effectively, for anyone who's not intensely steeped in the
> details of MVCC.
+1.
This proposal sounds like it would target batch jobs, because those
are the kinds of jobs that where you can predict in advance what
tables will be needed. I don't know whether my personal set of
problems with MVCC syncs up with anyone else's, but this is rarely how
I get bitten. Usually, what happens is that a user session (psql or
web server connection) gets left in a transaction for days or weeks.
Now the batch jobs (which are doing lots of updates) start creating
tons of bloat, but it's not their snapshot that is causing the
problem.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-08-07 14:50:39 | Re: Visibility Groups |
| Previous Message | Tom Lane | 2008-08-07 14:48:06 | Re: Infrastructure changes for recovery |