> What's more doing similar insert (even much larger) to the 'offers' table
does not affect the benchmark results in any significant way...
Just want clarify myself here: Insert to 'offers' table does not cause the
slowdown. Only insert to 'categories' causes the problem.
On 2013-09-17 08:40:23 -0500, Merlin Moncure wrote:
> > If you ever get into the situation I mistakenly referred to again, I'd
> > strongly suggest recompling postgres with -fno-omit-frame-pointer. That
> > makes hierarchical profiles actually useful which can help tremendously
> > with diagnosing
On Tue, Sep 17, 2013 at 8:35 AM, Andres Freund wrote:
> On 2013-09-17 08:32:30 -0500, Merlin Moncure wrote:
>> On Tue, Sep 17, 2013 at 8:24 AM, Andres Freund
>> wrote:
>> > On 2013-09-17 08:18:54 -0500, Merlin Moncure wrote:
>> >> Do you think it's worth submitting the lock avoidance patch for f
On 2013-09-17 08:32:30 -0500, Merlin Moncure wrote:
> On Tue, Sep 17, 2013 at 8:24 AM, Andres Freund wrote:
> > On 2013-09-17 08:18:54 -0500, Merlin Moncure wrote:
> >> Do you think it's worth submitting the lock avoidance patch for formal
> >> review?
> >
> > You mean the bufmgr.c thing? General
On Tue, Sep 17, 2013 at 8:24 AM, Andres Freund wrote:
> On 2013-09-17 08:18:54 -0500, Merlin Moncure wrote:
>> Do you think it's worth submitting the lock avoidance patch for formal
>> review?
>
> You mean the bufmgr.c thing? Generally I think that that code needs a
> good of scalability work - t
On 2013-09-17 08:18:54 -0500, Merlin Moncure wrote:
> On Tue, Sep 17, 2013 at 6:59 AM, Andres Freund wrote:
> > Hi,
> >
> > On 2013-09-17 17:55:01 +0600, Дмитрий Дегтярёв wrote:
> >> We have not been able to reproduce this problem on a test servers. Use this
> >> patch to production servers do not
On Tue, Sep 17, 2013 at 6:59 AM, Andres Freund wrote:
> Hi,
>
> On 2013-09-17 17:55:01 +0600, Дмитрий Дегтярёв wrote:
>> We have not been able to reproduce this problem on a test servers. Use this
>> patch to production servers do not dare.
>>
>> In the course of studying the problems we have iden
Hi,
On 2013-09-17 17:55:01 +0600, Дмитрий Дегтярёв wrote:
> We have not been able to reproduce this problem on a test servers. Use this
> patch to production servers do not dare.
>
> In the course of studying the problems we have identified that many queries
> are executed on the slave several ti
Hello.
We have not been able to reproduce this problem on a test servers. Use this
patch to production servers do not dare.
In the course of studying the problems we have identified that many queries
are executed on the slave several times slower. On master function
heap_hot_search_buffer execute
