[PERFORM] Simple select hangs while CPU close to 100%

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

Re: [PERFORM] Simple select hangs while CPU close to 100%

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 -Original Message- From: Pavel Stehule [mailto:[EMAIL PROTECTED] Sent: Sunday, July 22, 2007 10:53 AM To: Joz

Re: [PERFORM] Simple select hangs while CPU close to 100%

The actual application does not have to perform this statement since, as you suggested; it keeps track of what got loaded. However, the table has to go thru a de-duplication process because bulk load is utilized to load the potentially large number (millions) of rows. All indexes were dropped for

Re: [PERFORM] Simple select hangs while CPU close to 100%

"live" rows has not returned the result for more than 6 hours after which I manually killed it. 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 S

Re: [PERFORM] Simple select hangs while CPU close to 100% - Analyze

table anymore. The plain VACUUM is satisfactory. Thanks for all the responses! Jozsef -Original Message- From: Bill Moran [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 3:29 PM To: Jozsef Szalay Cc: Pavel Stehule; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Simple

[PERFORM] Incorrect Total runtime Reported by Explain Analyze!?

Hi All,   I have seen it on occasion that the total runtime reported by explain analyze was much higher than the actual time the query needed to complete. The differences in my case ranged between 20-120 seconds. I’m just curious if anyone else has experienced this and whether there is so

Re: [PERFORM] Incorrect Total runtime Reported by Explain Analyze!?

It might be. I'm running on Fedora Linux kernel 2.6.5-1.358smp, GCC 3.3.3, glibc-2.3.3-27 -Original Message- From: Richard Huxton [mailto:[EMAIL PROTECTED] Sent: Thursday, January 26, 2006 10:50 AM To: Jozsef Szalay Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Inco

Re: [PERFORM] Incorrect Total runtime Reported by Explain Analyze!?

, 2006 11:57 AM To: Richard Huxton Cc: Jozsef Szalay; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Incorrect Total runtime Reported by Explain Analyze!? On Thu, Jan 26, 2006 at 04:49:59PM +, Richard Huxton wrote: > Jozsef Szalay wrote: > >I have seen it on occasion that

[PERFORM] Like 'name%' is not using index

Hi all,   I have to provide a pretty standard query that should return every row where the NAME attribute begins with a specific string. The type of the NAME column is varchar. I do have an index for this column. One would think that Postgres will use the index to look up the matches, but

Re: [PERFORM] Like 'name%' is not using index

The var_char_pattern_ops operator group has made the difference. Thanks for the help! Jozsef -Original Message- From: Mark Kirkwood [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 7:29 PM To: Jozsef Szalay Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Like '

Re: [PERFORM] FWD: Update touches unrelated indexes?

Hi Tom, >This surprises you why? I don't know anything about how PG stores keys along with their references to the actual rows but my assumption was that that reference is some sort of an index into a table that maps the reference to an actual disk/file address. So even if the row or the page wit