Re: Updates, deletes and inserts are very slow. What can I do make them bearable?

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.

In response to

Responses

Browse pgsql-general by date

  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