On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote: > On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote: > > Andres is on the verge of convincing me that we need to support > > singleton FOR SHARE without multixacts due to performance concerns. > > I don't really see any arguments against doing so. We aren't in a that > big shortage of flags and if we need more than available I think we can > free some (e.g. XMAX/XMIN_INVALID).
The patch currently leaves two unallocated bits. Reclaiming currently-used bits means a binary compatibility break. Until we plan out such a thing, reclaimable bits are not as handy as never-allocated bits. I don't think we should lightly expend one of the final two. > > It > > would be useful for more people to chime in here: is FOR SHARE an > > important case to cater for? I wonder if using FOR KEY SHARE (keep > > performance characteristics, but would need to revise application code) > > would satisfy Andres' users, for example. > > It definitely wouldn't help in the cases I have seen because the point > is to protect against actual content changes of the rows, not just the > keys. > Note that you actually need to use explicit FOR SHARE/UPDATE for > correctness purposes in many scenarios unless youre running in 9.1+ > serializable mode. And that cannot be used in some cases (try queuing > for example) because the rollback rates would be excessive. I agree that tripling FOR SHARE cost is risky. Where is the added cost concentrated? Perchance that multiple belies optimization opportunities. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
