Re: [HACKERS] Statement-level rollback
От | Vladimir Sitnikov |
---|---|
Тема | Re: [HACKERS] Statement-level rollback |
Дата | |
Msg-id | CAB=Je-E3jTFic3BBMWqbrEAP+TwrE=jN8F-ko5x7+cGZkaiqJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Statement-level rollback ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: [HACKERS] Statement-level rollback
Re: [HACKERS] Statement-level rollback |
Список | pgsql-hackers |
Tsunakawa> PgJDBC has supported the feature with autosave parameter only recently
PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07, see https://github.com/pgjdbc/pgjdbc/pull/477 )
PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07, see https://github.com/pgjdbc/pgjdbc/pull/477 )
Tsunakawa> The point raised in this thread was that that creates
Tsunakawa> too much network overhead, so a backend-based solution would be preferable.
Tsunakawa> We haven't seen any numbers or other evidence to quantify that claim, so
Tsunakawa> maybe it's worth looking into that some more
Tsunakawa> too much network overhead, so a backend-based solution would be preferable.
Tsunakawa> We haven't seen any numbers or other evidence to quantify that claim, so
Tsunakawa> maybe it's worth looking into that some more
The performance overhead for "SELECT" statement (no columns, just select) statement over localhost is 36±4 us vs 38±3 us (savepoint is pipelined along with user-provided query). That is network overhead is close to negligible.
As far as I understand, the main problem with savepoints is they would consume memory even in case the same savepoint is reassigned again and again.
In other words, "savepoint; insert;savepoint; insert;savepoint; insert;savepoint; insert;savepoint; insert;" would allocate xids and might blow up backend's memory.
I see no way driver can workaround that, so it would be great if backend could release memory or provide a way to do so.
Adding protocol messages would blow pgbouncer, etc things, so it makes sense to refrain from new messages unless it is absolutely required.
Vladimir
В списке pgsql-hackers по дате отправления: