| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Agnes Bocchino <agnes(dot)bocchino(at)bull(dot)net>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Wal -long transaction |
| Date: | 2006-03-13 18:35:44 |
| Message-ID: | 873bhmkxa7.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Of course, there's no free lunch --- the price we pay for escaping
> rollback-segment-overflow is table bloat if you don't vacuum often
> enough.
Well it's worse than that. If you have long-running transactions that would
cause rollback-segment-overflow in Oracle then the equivalent price in
Postgres would be table bloat *regardless* of how frequently you vacuum.
I suppose you can argue it's not "bloat" as long as you reach a steady state.
But the extra space in the tables is a performance cost on every sequential
scan and on every cache miss it causes whatever you call it.
I'm not saying I like rollback segments better, just yes, TANSTAAFL.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-03-13 18:44:59 | Re: Transaction eating up all RAM |
| Previous Message | Merlin Moncure | 2006-03-13 18:35:43 | Re: Table locks and serializable transactions. |