Re: pessimal trivial-update performance
От | Pierre C |
---|---|
Тема | Re: pessimal trivial-update performance |
Дата | |
Msg-id | op.vfc7xobzeorkce@apollo13 обсуждение исходный текст |
Ответ на | Re: pessimal trivial-update performance (Jesper Krogh <jesper@krogh.cc>) |
Ответы |
Re: pessimal trivial-update performance
Re: pessimal trivial-update performance |
Список | pgsql-hackers |
> The problem can generally be written as "tuples seeing multiple > updates in the same transaction"? > > I think that every time PostgreSQL is used with an ORM, there is > a certain amount of multiple updates taking place. I have actually > been reworking clientside to get around multiple updates, since they > popped up in one of my profiling runs. Allthough the time I optimized > away ended being both "roundtrip time" + "update time", but having > the database do half of it transparently, might have been sufficient > to get me to have had a bigger problem elsewhere.. > > To sum up. Yes I think indeed it is a real-world case. > > Jesper On the Python side, elixir and sqlalchemy have an excellent way of handling this, basically when you start a transaction, all changes are accumulated in a "session" object and only flushed to the database on session commit (which is also generally the transaction commit). This has multiple advantages, for instance it is able to issue multiple-line statements, updates are only done once, you save a lot of roundtrips, etc. Of course it is most of the time not compatible with database triggers, so if there are triggers the ORM needs to be told about them.
В списке pgsql-hackers по дате отправления: