Search Postgresql Archives

Re: UPDATE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



c k wrote:

> CREATE TABLE accgroups
> (
>   accgroupid serial NOT NULL,
>   accgroupidname character varying(150) NOT NULL DEFAULT ''::character
> varying,
>   accgroupname character varying,
>   createdby integer DEFAULT 0,
>   createdtimestamp timestamp without time zone DEFAULT
> ('now'::text)::timestamp without time zone,
>   locked smallint,
>   lastmodifiedby integer DEFAULT 0,
>   lastmodifiedtimestamp timestamp without time zone,
>   remark character varying(255) DEFAULT NULL::character varying,
>   cobranchid integer DEFAULT 0,
> .
> .
> .
> .
>   againstid integer DEFAULT 0,
> )
> WITH (OIDS=FALSE);

That "..." might be rather important. How big ARE these records?

Remember, PostgreSQL uses a MVCC approach to transactional isolation.
Unless Pg can take short-cuts (as it sometimes can when, for example,
there is only one active transaction) it must write NEW COPIES of each
record. It can't just update the existing ones.

Effectively, Pg must do an INSERT of the updated record then a DELETE of
the old one. All fields, not just the updated field, must be read and
written.

Some other databases use a locking approach instead. They can just write
the new values in place. The I/O required is dramatically reduced. On
the other hand, other concurrent transactions can't do anything while
you're working with those records, you're more prone to deadlock
situations, achieving decent concurrency is much more difficult, etc. If
you're using something horrifying like MyISAM tables where there IS no
rollback, there's no need to maintain a rollback log or anything like
that. Even with it the I/O is still much less than what Pg requires.

AFAIK if you run the UPDATE while there are no other concurrent
transactions, Pg will write the new values in-place. It still updates
the WAL first, but it won't create whole new copies of each record as
well. That's the case at least if the field you're updating isn't
involved in any indexes; I think doing this relies on HOT, and won't
work if the column being altered is involved in one or more indexes.

--
Craig Ringer

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux