From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cost limited statements RFC |
Date: | 2013-05-23 23:56:33 |
Message-ID: | CAGTBQpbP9jWvatggynwGRMA5YLBaBCg9aSwnYvi1QxPv9PdzeA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 23, 2013 at 8:46 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 5/23/13 7:34 PM, Claudio Freire wrote:
>>
>> Why not make the delay conditional on the amount of concurrency, kinda
>> like the commit_delay? Although in this case, it should only count
>> unwaiting connections.
>
>
> The test run by commit_delay is way too heavy to run after every block is
> processed. That code is only hit when there's a commit, which already
> assumes a lot of overhead is going on--the disk flush to WAL--so burning
> some processing/lock acquisition time isn't a big deal. The spot where
> statement delay is going is so performance sensitive that everything it
> touches needs to be local to the backend.
Besides of the obvious option of making a lighter check (doesn't have
to be 100% precise), wouldn't this check be done when it would
otherwise sleep? Is it so heavy still in that context?
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2013-05-24 00:06:40 | Re: Cost limited statements RFC |
Previous Message | Greg Smith | 2013-05-23 23:46:49 | Re: Cost limited statements RFC |