On 7 July 2015 at 12:55, Filipe Pina <filipe.pina@xxxxxxxxxxxxx> wrote: > On Ter, Jul 7, 2015 at 1:41 , Adrian Klaver <adrian.klaver@xxxxxxxxxxx> > wrote: >> Still not sure what is you are trying to accomplish. Is it really necessary >> that every transaction be serialized? Or to put it another way, why are you >> running in serializable by default? Or yet another way, what is the problem >> you are trying to solve with serialized transactions? > > Exactly, that's the twist I've decided after some tests yesterday (the "lock > all tables on last try" degraded performance in an obscene way): giving up > on serializable by default. > > I wanted to use serializable so developers wouldn't have to worry about > properly using locks, but implementing this "serialization failure" handler > is becoming a major headache... What Adrian was trying to get out of you is why you think you need those locks. You're working with an RDBMS, it does the job of keeping data integrity in a multi-user environment already. You can trust it do do that well. So unless you're doing something really special, you shouldn't need to lock anything. Among the special cases where you do need locks are things like needing a gapless sequence (invoice numbers come to mind); things like that. So once again, what do you need those locks for? P.S. Please don't top-post on this list. I had to edit your message to fix the flow of the conversation. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
