Merlin Moncure wrote:
> *) For off-cycle release work that would help enable patches with
> complex performance trade-offs (I'm working up another patch that has
> even more compelling benefits and risks in the buffer allocator), We
> desperately need a standard battery of comprehensive performa
On Tue, Mar 26, 2013 at 03:06:30PM +, Simon Riggs wrote:
> > More generally, the fact that a patch has some user-frobbable knob
> > does not mean that it's actually a good or even usable solution. As
> > everybody keeps saying, testing on a wide range of use-cases would be
> > needed to prove
On 26 March 2013 14:44, Tom Lane wrote:
> Simon Riggs writes:
>> So please, lets go with a simple solution now that allows users to say
>> what they want.
>
> Simon, this is just empty posturing, as your arguments have nothing
> whatsoever to do with whether the above description applies to your
Simon Riggs writes:
> So please, lets go with a simple solution now that allows users to say
> what they want.
Simon, this is just empty posturing, as your arguments have nothing
whatsoever to do with whether the above description applies to your
patch.
More generally, the fact that a patch has
On Tue, Mar 26, 2013 at 7:30 AM, Simon Riggs wrote:
> On 26 March 2013 11:33, Robert Haas wrote:
>> On Tue, Mar 26, 2013 at 5:27 AM, Simon Riggs wrote:
>>> On 26 March 2013 01:35, Greg Stark wrote:
On Tue, Mar 26, 2013 at 12:00 AM, Simon Riggs
wrote:
> I'll bet you all a beer at
On 26 March 2013 11:33, Robert Haas wrote:
> On Tue, Mar 26, 2013 at 5:27 AM, Simon Riggs wrote:
>> On 26 March 2013 01:35, Greg Stark wrote:
>>> On Tue, Mar 26, 2013 at 12:00 AM, Simon Riggs wrote:
I'll bet you all a beer at PgCon 2014 that this remains unresolved at
that point.
>>>
On Tue, Mar 26, 2013 at 5:27 AM, Simon Riggs wrote:
> On 26 March 2013 01:35, Greg Stark wrote:
>> On Tue, Mar 26, 2013 at 12:00 AM, Simon Riggs wrote:
>>> I'll bet you all a beer at PgCon 2014 that this remains unresolved at
>>> that point.
>>
>> Are you saying you're only interested in working
On 26 March 2013 01:35, Greg Stark wrote:
> On Tue, Mar 26, 2013 at 12:00 AM, Simon Riggs wrote:
>> I'll bet you all a beer at PgCon 2014 that this remains unresolved at
>> that point.
>
> Are you saying you're only interested in working on it now? That after
> 9.3 is release you won't be interes
On Mon, 2013-03-25 at 12:21 +, Greg Stark wrote:
> On Mon, Mar 25, 2013 at 2:50 AM, Greg Smith wrote:
> > The idea I was thinking about is refactoring the background writer's role in
> > hint bit maintenance
>
> A good first step might be to separate the "dirty" bit into two bits.
> "mandator
On Tue, Mar 26, 2013 at 12:00 AM, Simon Riggs wrote:
> I'll bet you all a beer at PgCon 2014 that this remains unresolved at
> that point.
Are you saying you're only interested in working on it now? That after
9.3 is release you won't be interested in working on it any more?
As you said we've be
Simon Riggs writes:
> On 25 March 2013 23:18, Tom Lane wrote:
>> This is clearly worth thinking about and trying to find better solutions
>> for. I'm only against trying to solve it in the 9.3 timeframe. It will
>> take a lot longer than that to get something that works tolerably well.
> I'll
On 25 March 2013 23:18, Tom Lane wrote:
> Greg Stark writes:
>> On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote:
>>> That would make it harder to construct a degenerate case
>
>> I don't think it's hard at all. It's the same as the case Simon wants
>> to solve except that the cost is incur
Greg Stark writes:
> On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote:
>> That would make it harder to construct a degenerate case
> I don't think it's hard at all. It's the same as the case Simon wants
> to solve except that the cost is incurred in a different way. Imagine
> a system where
On Mon, Mar 25, 2013 at 5:57 PM, Greg Stark wrote:
> On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote:
>> That would make it harder to construct a degenerate case
>
> I don't think it's hard at all. It's the same as the case Simon wants
> to solve except that the cost is incurred in a differ
On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner wrote:
> That would make it harder to construct a degenerate case
I don't think it's hard at all. It's the same as the case Simon wants
to solve except that the cost is incurred in a different way. Imagine
a system where there's a huge data load to
Simon Riggs wrote:
> On 25 March 2013 20:44, Kevin Grittner wrote:
>> This is absolutely a real-world problem, but I disagree that the
>> solution you propose is risk-free. It would be trivial to
>> construct a test which would show massive performance degradation.
>
> It is trivial to show mas
On 25 March 2013 20:44, Kevin Grittner wrote:
> Simon Riggs wrote:
>> Merlin Moncure wrote:
>
>>> we need testing against real world workloads, or at least a much
>>> better synthetic one than pgbench, which per recent discussions
>>> is probably the top objective of the project (a performance
>
On Mon, Mar 25, 2013 at 1:05 PM, Simon Riggs wrote:
> On 25 March 2013 14:26, Merlin Moncure wrote:
>
>> This is pretty similar to the proposal Atri and I just recently made.
>> I am 100% in agreement that something must be done here...SELECT has
>> none of the i/o mitigation features that vacuum
Simon Riggs wrote:
> Merlin Moncure wrote:
>> we need testing against real world workloads, or at least a much
>> better synthetic one than pgbench, which per recent discussions
>> is probably the top objective of the project (a performance
>> farm, etc.).
>
> Self-tuning the background workload
On 25 March 2013 14:26, Merlin Moncure wrote:
> This is pretty similar to the proposal Atri and I just recently made.
> I am 100% in agreement that something must be done here...SELECT has
> none of the i/o mitigation features that vacuum has. Is your idea
> better? probably (although you have t
> This is pretty similar to the proposal Atri and I just recently made.
> I am 100% in agreement that something must be done here...SELECT has
> none of the i/o mitigation features that vacuum has. Is your idea
> better? probably (although you have to give a small penalty for a user
> facing tunab
On Sun, Mar 24, 2013 at 6:14 AM, Simon Riggs wrote:
> vacuum_delay is designed to slow down VACUUMs from writing too many
> blocks. However, SELECTs also dirty data blocks but are NOT slowed
> down by vacuum_delay.
>
> So the current situation is that a large SELECT operates similarly to
> a VACUU
On Mon, Mar 25, 2013 at 2:50 AM, Greg Smith wrote:
> The idea I was thinking about is refactoring the background writer's role in
> hint bit maintenance
A good first step might be to separate the "dirty" bit into two bits.
"mandatory dirty" and "optional dirty". (Or maybe "hard dirty" and
"soft d
On 25 March 2013 02:50, Greg Smith wrote:
> On 3/24/13 7:14 AM, Simon Riggs wrote:
>>
>> Patch to implement is a few hours work. The only complexity is
>> deciding how to handle SQL in functions to which I would say, as
>> simply as possible.
>
>
> Like the Page replacement ideas, the throttle
On 3/24/13 7:14 AM, Simon Riggs wrote:
Patch to implement is a few hours work. The only complexity is
deciding how to handle SQL in functions to which I would say, as
simply as possible.
Like the Page replacement ideas, the throttle on how fast something like
this will get done depends not
On Sun, Mar 24, 2013 at 9:02 PM, Simon Riggs wrote:
> ...and as a result, the rest of your comments don't apply at all to
> the proposal. Sorry about that confusion.
How do you figure that?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 24 March 2013 13:38, Tom Lane wrote:
> Simon Riggs writes:
>> Can we do this now?
>
> No.
>
> We are trying to get 9.3 out the door, not undertake design, coding,
> and testing of entirely new behaviors which will have complex
> performance tradeoffs. This sounds like a great project for earl
On 24 March 2013 13:29, Greg Stark wrote:
> On Sun, Mar 24, 2013 at 11:14 AM, Simon Riggs wrote:
>> Proposal is to prevent SELECTs from causing more than N buffers from
>> being dirtied by hint bit setting and block cleanup.
> I'm guessing you mean that there would be a global variable somewhere
Simon Riggs writes:
> Can we do this now?
No.
We are trying to get 9.3 out the door, not undertake design, coding,
and testing of entirely new behaviors which will have complex
performance tradeoffs. This sounds like a great project for early in
the 9.4 development cycle, but it's way too late
On Sun, Mar 24, 2013 at 11:14 AM, Simon Riggs wrote:
> Proposal is to prevent SELECTs from causing more than N buffers from
> being dirtied by hint bit setting and block cleanup.
I think you need to clarify what you mean by this.
I'm guessing you mean that there would be a global variable somewh
vacuum_delay is designed to slow down VACUUMs from writing too many
blocks. However, SELECTs also dirty data blocks but are NOT slowed
down by vacuum_delay.
So the current situation is that a large SELECT operates similarly to
a VACUUM, throwing out many dirty blocks and using additional I/O
resou
31 matches
Mail list logo
