Re: Elide null updates

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Elide null updates
Date: 2008-12-16 21:43:27
Message-ID: 494820FF.5070605@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

James Mansion wrote:
> I saw on a summary for 8.4 that there's a generic function for use as
> a before row trigger that will elide null updates (ie replacement with
> an identical row).
>
> I can see that this is great - but I was wondering if it should be
> more integrated and turned on in the db schema.
>
> Trivially, doing so would mean that there is less of an issue trying
> to integrate with a custom user before trigger, although that's really
> no more than an inconvenience.
>
> I understand that there is an argument for not making it the default
> behaviour given that trigger execution and locking are both affected
> if we do elide the update completely, but it occured to me that while
> I might want the trigger and locking behaviour, I probably never want
> the actual database image copy to happen. Doing so will needlessly
> bloat the database file and give the vacuum procedure work to do - and
> it seems interfere with the new optimisations relating to pages that
> are all visible in all transactions.
>
> Would it be possible to determine a null update cheaply and retain the
> locking and trigger execution, but elide the actual row copy - and in
> particular the associated impact in terms of setting status flags etc?
>
> I guess this would need to be handled at a lower level than the
> trigger approach - and would need an option that is integrated into
> the schema, so we can elide the copy, and optionally the trigger
> execution, and optionally the lock.
>
>

I don't follow what you're saying.

If an update is skipped by a trigger, nothing new is written to disk,
and there should be nothing to vacuum from it. That's why this trigger
can speed up certain update queries enormously.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2008-12-16 21:52:19 Re: Another issue in default-values patch: defaults expanded too soon
Previous Message Zdenek Kotala 2008-12-16 21:38:16 WIP: pre-upgrade page reservation