Re: Is full-row updates slower than single-value updates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Björn Lindqvist <bjourne(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Is full-row updates slower than single-value updates
Date: 2010-07-01 23:01:11
Message-ID: 28217.1278025271@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?ISO-8859-1?Q?Bj=F6rn_Lindqvist?= <bjourne(at)gmail(dot)com> writes:
> Den 28 juni 2010 20.22 skrev Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> But assigning a new value to a column costs something, even if it
>> happens to be equal to the previous value.

> But do I really need to worry about the cost of casting strings to
> ints and other such parsing operations?

Integers? Maybe not. Timestamps? Probably you ought to think about
it. Strings long enough to need toasting? Definitely.

> No column in the table is a toast column, although there are a few
> string columns with quite long urls. If they are indexed, does
> updating them with the same data trigger index updates?

It shouldn't ordinarily, but if the data is long enough to get toasted
then updates are going to happen anyway, both in the toast table and
the main table.

The long and the short of it here is that being lazy is going to cost
you eventually. Maybe it's all right in a single small application
where you can be confident about what sort of data will be stored, but
an allegedly general-purpose ORM should *not* be making that sort of
assumption.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gerhard Heift 2010-07-01 23:32:03 change array dimension
Previous Message John R Pierce 2010-07-01 22:39:06 Re: problems with encoding and accent letters