Re: BUG #14231: logical replication wal sender process spins when using error traps in function

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, blake(at)rcmail(dot)com
Subject: Re: BUG #14231: logical replication wal sender process spins when using error traps in function
Date: 2016-07-19 13:35:24
Message-ID: d4a5bf3c-f03b-92be-9f34-a772406f1817@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 07/19/2016 07:27 AM, Andres Freund wrote:
> Hi,
>
> On 2016-07-19 07:04:43 +0200, Tomas Vondra wrote:
>> So, I've spent a few hours experimenting with this idea, and I
>> believe it seems like a good way forward. Attached is an early WIP
>> patch that does this:
>
> Cool! Thanks for looking into this.
>
>
>> I'm not sure whether the SlabContext is needed here - perhaps
>> AllocSets would do equally well, at least in this case. I however
>> wonder whether the existing local slab cache can actually improve
>> anything, because what I see is a long sequence of pallocs()
>> followed by a long sequence of pfrees(), which makes any reuse
>> impossible. But I guess there are other cases where the palloc()
>> and pfree() calls are mixed.
>
> In something more oltp like you'll see exactly that. IIRC, in
> pgbench, we pretty much never allocate for the slab allocated stuff,
> after some warmup.

Yeah. Haven't done much testing at night. I think we'll need a set of
test cases to validate the changes. We certainly don't want to improve
one case and regress two others.

>
>> The other thing is that splitting the tuple context into two parts
>> seems a bit wasteful - this mostly follows the MaxHeapTupleSize
>> idea from the existing slab code, but how many tuples actually are
>> this big?
>
> The issue is that allocating them differently sized leads to massive
> memory fragmentation over time.
>

Sure, in all allocators we basically trade space and time efficiency. If
we could get some apriori some estimate of the tuple size, we could
probably tune this. It's just that ~8kB per tuple seems a bit too high.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message krayner 2016-07-19 14:00:27 BUG #14260: psqlODBC does not support sslXXXXX variables
Previous Message zzia88 2016-07-19 12:57:53 BUG #14259: i want to store XML version in our table postgres table.