Horton

Re: delta relations in AFTER triggers

Kevin Grittner <kgrittn@gmail.com>

View thread View on postgr.es
From: Kevin Grittner <kgrittn@gmail.com>
To: Adam Brusselback <adambrusselback@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-03T10:39:53Z
Lists: pgsql-hackers 
On Wed, Nov 2, 2016 at 4:09 PM, Adam Brusselback
<adambrusselback@gmail.com> wrote:
>> There may be some situations where crawling the indexes a row at a
>> time will perform better than this by enough to want to retain that
>> option.
>
> If an index existed, wouldn't it still be able to use that in the set-based
> implementation?

Yes.  The optimizer would compare plans and pick the lowest cost.

> Is there something which would make doing the check
> set-based ever worse than row based inherently?

I'm not sure.  I doubt that it would ever lose by very much, but
only benchmarking can really answer that question.

Anyway, it's probably premature to get too far into it now.  It
just occurred to me that it might be a worthwhile project once the
transition tables are available, so I did a quick set of triggers
to see what the potential was in a "best case" scenario.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Don't permit transition tables with TRUNCATE triggers.

  2. Pass EXEC_FLAG_REWIND when initializing a tuplestore scan.

  3. Faster expression evaluation and targetlist projection.

  4. Remove obsoleted code relating to targetlist SRF evaluation.

  5. Implement syntax for transition tables in AFTER triggers.