On 13/09/16 22:24, Robert Haas wrote:
On Wed, Sep 7, 2016 at 9:14 PM, Craig Ringer
<craig.rin...@2ndquadrant.com> wrote:
That's probably going to be one of the smaller costs. Doing this with
bgworkers won't be cheap, but you need to consider the alternative.
Factoring out all transaction-specific data currently stored in or
pointed to by globals into a transaction state struct that can be
swapped out. Making PgXact and PGPROC capable of representing
multiple/suspended transactions. Lots more. Much of which would have a
performance impact on all day to day operations whether or not
autononomous xacts are actually in use.
I haven't looked into it in detail. Peter can probably explain more
and better. I'm just pointing out that I doubt there's any way to do
this without a cost somewhere, and having that cost limited to actual
uses of autonomous xacts would be nice.
I don't really believe this line of argument. I mean, sure, it's nice
to limit the cost of features to the people who are using those
features. Totally agreed. But if the cost really wouldn't be that
high anyway, which I suspect is the case here, then that argument
loses its force. And if that separation increases the performance
cost of the feature by two or three orders of magnitude in realistic
use cases, then you really have to wonder if you've picked the right
approach.
Again, I'm not saying that having ways to run commands in the
background in a worker isn't useful. If I thought that wasn't useful,
I would not have written pg_background and developed it as far as I
did. But I still don't think that's the right way to implement an
autonomous transaction facility.
I mostly agree. I think if this was called something like background
transactions it might be better. It's definitely useful functionality
but the naming is clearly contentious. It won't stop people using it for
same use-cases as autonomous transactions though (which is fine).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
