On Wed, Sep 7, 2016 at 9:14 PM, Craig Ringer
<craig.ringer@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