On Thu, Sep 26, 2013 at 10:14 PM, Merlin Moncure wrote:
> On Thu, Sep 26, 2013 at 6:08 PM, Andres Freund wrote:
>> On 2013-08-27 12:17:55 -0500, Merlin Moncure wrote:
>>> On Tue, Aug 27, 2013 at 10:55 AM, Andres Freund
>>> wrote:
>>> > On 2013-08-27 09:57:38 -0500, Merlin Moncure wrote:
>>> >>
On Thu, Sep 26, 2013 at 6:08 PM, Andres Freund wrote:
> On 2013-08-27 12:17:55 -0500, Merlin Moncure wrote:
>> On Tue, Aug 27, 2013 at 10:55 AM, Andres Freund
>> wrote:
>> > On 2013-08-27 09:57:38 -0500, Merlin Moncure wrote:
>> >> + bool
>> >> + RecoveryMightBeInProgress(void)
>> >> + {
>> >> +
On 2013-08-27 12:17:55 -0500, Merlin Moncure wrote:
> On Tue, Aug 27, 2013 at 10:55 AM, Andres Freund
> wrote:
> > On 2013-08-27 09:57:38 -0500, Merlin Moncure wrote:
> >> + bool
> >> + RecoveryMightBeInProgress(void)
> >> + {
> >> + /*
> >> + * We check shared state each time only until
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
On Tue, Aug 27, 2013 at 10:55 AM, Andres Freund wrote:
> On 2013-08-27 09:57:38 -0500, Merlin Moncure wrote:
>> + bool
>> + RecoveryMightBeInProgress(void)
>> + {
>> + /*
>> + * We check shared state each time only until we leave recovery mode.
>> We
>> + * can't re-enter recovery,
On 2013-08-27 09:57:38 -0500, Merlin Moncure wrote:
> + bool
> + RecoveryMightBeInProgress(void)
> + {
> + /*
> + * We check shared state each time only until we leave recovery mode. We
> + * can't re-enter recovery, so there's no need to keep checking after
> the
> + * shared v
On Tue, Aug 27, 2013 at 9:12 AM, Merlin Moncure wrote:
> Something like the attached. Note, this patch is for research
> purposes only and should *not* be applied to your production
> environment.
Here is a revised version that is missing the spurious whitespace edit.
merlin
recovery2.patch
D
On Tue, Aug 27, 2013 at 8:38 AM, Merlin Moncure wrote:
> On Tue, Aug 27, 2013 at 8:23 AM, Merlin Moncure wrote:
>> It looks like you're hitting spinlock connection inside
>> heap_page_prune_opt(). Which is commented:
>> * Note: this is called quite often. It's important that it fall out quickl
On Tue, Aug 27, 2013 at 8:23 AM, Merlin Moncure wrote:
> It looks like you're hitting spinlock connection inside
> heap_page_prune_opt(). Which is commented:
> * Note: this is called quite often. It's important that it fall out quickly
> * if there's not any use in pruning.
>
> This in turn ca
On Tue, Aug 27, 2013 at 2:57 AM, Дмитрий Дегтярёв wrote:
> Hello.
>
> Exist 2 identical server DELL PowerEdge™ R720, CPU Dual Intel® Xeon® E5-2620
> Hexa-Core inkl, RAM 256Gb, RAID-10 8 x 600 GB SAS 6 Gb/s 15000 rpm.
>
> $ cat /etc/fedora-release
> Fedora release 19
>
> $ postgres --version
> post
Hello.
Exist 2 identical server DELL PowerEdge™ R720, CPU Dual Intel® Xeon®
E5-2620 Hexa-Core inkl, RAM 256Gb, RAID-10 8 x 600 GB SAS 6 Gb/s 15000 rpm.
$ cat /etc/fedora-release
Fedora release 19
$ postgres --version
postgres (PostgreSQL) 9.2.4
Data ~220Gb and Indexes ~140Gb
iowait ~0.2-0.5. D
On Tuesday 13 February 2007 10:36, "Campbell, Lance" <[EMAIL PROTECTED]>
wrote:
> We have 12+ schemas in 1 database. When I do a unix "top" command I
> notice one postmaster process has 100% CPU usage. This process just
> stays at 100% to 99% CPU usage. There are other postmaster processes
> tha
Postgres 8.1
Linux Redhat AS 4.X
4 processor box
We have 12+ schemas in 1 database. When I do a unix "top" command I
notice one postmaster process has 100% CPU usage. This process just
stays at 100% to 99% CPU usage. There are other postmaster processes
that pop up. They use hardly no CPU or
> Something seems to have truncated your EXPLAIN output, but anyway we
> can see where the problem is:
I copied it from pgAdmin in 640x480 screen resolution in XP
Maybe pgAdmin bug ?
> The planner is expecting to get one row from "dok" passing the filter
> condition, and hence chooses a plan tha
"Andrus" <[EMAIL PROTECTED]> writes:
> Here it is running in my local computer. I'm expecting run time no more 1
> second
Something seems to have truncated your EXPLAIN output, but anyway we
can see where the problem is:
> " -> Seq Scan on dok (cost=0.00..787.80 rows=1 width=39)
>
> You have ANALYZEd all these tables recently, I hope? The planner
> certainly doesn't think this query will take very long.
I have autovacuum running so I expect it takes care of ANALYZE, isn't it ?
I ran also analyze command before running explain analyze.
> To find out what's wrong, you're g
"Andrus" <[EMAIL PROTECTED]> writes:
> I have small database running in 8.1.3 in W2K server.
> The following query causes Postgres process to use 100% CPU and seems to run
> forever.
> If I change '1EEKPANT' to less frequently used item code, it runs fast.
You have ANALYZEd all these tables rece
I have small database running in 8.1.3 in W2K server.
The following query causes Postgres process to use 100% CPU and seems to run
forever.
If I change '1EEKPANT' to less frequently used item code, it runs fast.
How to speed it up ?
set search_path to public,firma2;
select rid.toode
FR
25 matches
Mail list logo
