From: | Tim Uckun <timuckun(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Updates, deletes and inserts are very slow. What can I do make them bearable? |
Date: | 2010-10-21 05:05:00 |
Message-ID: | AANLkTimvyUsi2btVo6f=5MMfi_u5zQK4iRn4YtxLsMLG@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> No, it isn't. This is a three-way join between consolidated_urls, cu,
> and tu --- the fact that cu is the same underlying table as
cu is an alias for consolidated_urls. tu is an alias for trending_urls.
There are only two tables in the query.
> consolidated_urls doesn't change that. And the join is
> underconstrained, causing each row of consolidated_urls to be joined
> to every row of the cu/tu join. That's why it's taking such an
> unreasonably long time --- you're generating many thousands of redundant
> updates to each row of consolidated_urls. You should just write this as
>
Once again there are only two tables in the query. The join clause is
inner join trending_urls tu on tu.consolidated_url_id = cu.id
> update consolidated_urls
> set screenshot_file_name = tu.screenshot_file_name,
> screenshot_content_type = tu.screenshot_content_type,
> screenshot_file_size = tu.screenshot_file_size,
> screenshot_status = tu.screenshot_status
> from trending_urls tu where tu.consolidated_url_id = consolidated_urls.id
>
> Postgres is a bit different from some other DBMSes in how it interprets
> UPDATE ... FROM syntax.
>
I'll try this too.
Anything to make this query complete in a reasonable amount of time.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-10-21 05:05:23 | Re: a query on stored procedures/functions in pgsql |
Previous Message | Pavel Stehule | 2010-10-21 05:00:37 | Re: a query on stored procedures/functions in pgsql |