| From: | Richard Huxton <dev(at)archonet(dot)com> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, Jochem van Dieten <jochemd(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
| Subject: | Re: Transaction Snapshots and Hot Standby |
| Date: | 2008-09-12 11:31:58 |
| Message-ID: | 48CA532E.8090102@archonet.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark wrote:
> In that case the problem is dealing with different usage patterns on different
> tables. There might be a way to solve just that use case such as deferring WAL
> records for those tables. That doesn't guarantee inter-table data consistency
> if there were other queries which read from those tables and updated other
> tables based on that data though. Perhaps there's a solution for that too
> though.
There was a suggestion (Simon - from you?) of a transaction voluntarily
restricting itself to a set of tables. That would obviously reduce the
impact of all the options where the accessed tables weren't being
updated (where update = vacuum + HOT if I've got this straight).
--
Richard Huxton
Archonet Ltd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2008-09-12 11:41:42 | Re: Transaction Snapshots and Hot Standby |
| Previous Message | Gregory Stark | 2008-09-12 11:25:42 | Re: Transaction Snapshots and Hot Standby |