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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
