On 10/20/07, Pavel Velikhov <[EMAIL PROTECTED]> wrote:
> Left the query running for 10+ hours and had to kill it. I guess
there
> really was no need to have lots of
> shared buffers (the hope was that postgresql will cache the whole
table). I
> ended up doing this step inside
> the application a
On 10/20/07, Pavel Velikhov <[EMAIL PROTECTED]> wrote:
> Left the query running for 10+ hours and had to kill it. I guess there
> really was no need to have lots of
> shared buffers (the hope was that postgresql will cache the whole table). I
> ended up doing this step inside
> the application as a
PROTECTED]>
Cc: Jonah H. Harris <[EMAIL PROTECTED]>; pgsql-performance@postgresql.org
Sent: Friday, October 19, 2007 8:17:48 PM
Subject: Re: [PERFORM] need help with a query
On Fri, Oct 19, 2007 at 09:11:36AM -0700, Pavel Velikhov wrote:
> Thanks for you help!
>
> Got a very d
Pavel Velikhov <[EMAIL PROTECTED]> writes:
> Got a very different query plan this time, with a hash join between links and
> articles. At least now postgres is using both shared memory buffers and
> working mem, but its still completely IO bound, only getting in 5-6% CPU once
> in a while. I gue
MAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Sent: Friday, October 19, 2007 7:52:58 PM
Subject: Re: [PERFORM] need help with a query
On 10/19/07, Pavel Velikhov <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am updating a big table (90M records) with data from another
rathe
On 10/19/07, Pavel Velikhov <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am updating a big table (90M records) with data from another rather
> large table (4M entries). Here is my update query:
>
> update links set target_size =
> ( select size from articles where articles.article_id =
> link
Hi,
I am updating a big table (90M records) with data from another rather large
table (4M entries). Here is my update query:
update links set target_size =
( select size from articles where articles.article_id = links.article_to)
I have built all the indexes one might need, increase
