Jozsef Szalay escribió:
> I don't know why ANALYZE would have any effect on a sequential scan of a
> table but it does appear to impact both performance and memory usage
> significantly.
It doesn't. What it does is provide the query optimizer with the
information that it needs to know that the t
gt;
> Jozsef
>
>
> -Original Message-
> From: Bill Moran [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 25, 2007 1:12 PM
> To: Jozsef Szalay
> Cc: Pavel Stehule; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Simple select hangs while CPU close to 100%
-Original Message-
> From: Bill Moran [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 25, 2007 1:12 PM
> To: Jozsef Szalay
> Cc: Pavel Stehule; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Simple select hangs while CPU close to 100%
>
> In response to &quo
PROTECTED]
Sent: Wednesday, July 25, 2007 1:12 PM
To: Jozsef Szalay
Cc: Pavel Stehule; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Simple select hangs while CPU close to 100%
In response to "Jozsef Szalay" <[EMAIL PROTECTED]>:
> Hi Pavel,
>
>
> Yes I did vacuum. I
ubject: Re: [PERFORM] Simple select hangs while CPU close to 100%
In response to "Jozsef Szalay" <[EMAIL PROTECTED]>:
> Hi Pavel,
>
>
> Yes I did vacuum. In fact the only way to "fix" this problem is
> executing a "full" vacuum. The plain vacuum
ete/insert may
be helpful.
> -Original Message-
> From: Pavel Stehule [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 22, 2007 10:53 AM
> To: Jozsef Szalay
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Simple select hangs while CPU close to 100%
>
> Hello
abase is a result of exhausting shared_buffers and hitting the
disks.
> -Original Message-
> From: Pavel Stehule [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 22, 2007 10:53 AM
> To: Jozsef Szalay
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Simple select han
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Tauno
Williams
Sent: Sunday, July 22, 2007 1:33 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Simple select hangs while CPU close to 100%
> I'm having this very disturbing problem.
2007/7/25, Jozsef Szalay <[EMAIL PROTECTED]>:
Hi Pavel,
Yes I did vacuum. In fact the only way to "fix" this problem is
executing a "full" vacuum. The plain vacuum did not help.
Regards,
Jozsef
It's question if vacuum was done.
Try vacuum verbose;
Maybe your max_fsm_pages is too low and y
sef Szalay
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Simple select hangs while CPU close to 100%
Hello
did you vacuum?
It's good technique do vacuum table after remove bigger number of rows.
Regards
Pavel Stehule
2007/7/22, Jozsef Szalay <[EMAIL PROTECTED]>:
>
>
> I’m having this very disturbing problem. I got a table with about
> 100,000 rows in it. Our software deletes the majority of these rows
> and then bulk loads another 100,000 rows into the same table. All this
> is happening within a single transaction. I then perform a simple
> “select count(*)
Hello
did you vacuum?
It's good technique do vacuum table after remove bigger number of rows.
Regards
Pavel Stehule
2007/7/22, Jozsef Szalay <[EMAIL PROTECTED]>:
I'm having this very disturbing problem. I got a table with about 100,000
rows in it. Our software deletes the majority of thes
I'm having this very disturbing problem. I got a table with about
100,000 rows in it. Our software deletes the majority of these rows and
then bulk loads another 100,000 rows into the same table. All this is
happening within a single transaction. I then perform a simple "select
count(*) from ..." s
13 matches
Mail list logo
