On 13/09/16 22:24, Robert Haas wrote:
> 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.
>
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
