Michael Nacos writes:
> The interesting thing is SQL_exec(sql,1) resulted in a different
> execution plan while the stray FROM was still in place.
Well, the stray FROM resulted in a useless cross-join, which would
have generated a lot of extra no-op row updates. I think what the
limit was doing
This is from within SPI_exec:
Nested Loop (cost=0.00..115947.18 rows=1952242 width=25) (actual
time=0.095..6425.291 rows=1952202 loops=1)
-> Index Scan using othertable_level_pkey on othertable
(cost=0.00..9.34 rows=1 width=25) (actual time=0.063..0.067 rows=1
loops=1)
Index Cond: ((le
Michael Nacos writes:
> the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
I was thinking of doing EXPLAIN ANALYZE via SPI_exec and seeing if you
got the same results as doing it manually.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi Tom,
the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
Index Scan using some_pkey on sometable (cost=0.00..8.58 rows=1 width=253)
(actual time=0.046..0.050 rows=1 loops=1)
Index Cond: (pkey = 123456)
Trigger so_and_so_on_change: time=62.309 calls=1
running an equ
Michael Nacos writes:
> I have been trying to improve the performance of a C trigger only to notice
> that the real bottleneck was the SPI execution of dynamic SQL statements. I
> had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
> targeting exactly one row each time for wri
Hi all,
I have been trying to improve the performance of a C trigger only to notice
that the real bottleneck was the SPI execution of dynamic SQL statements. I
had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
targeting exactly one row each time for writing. This simple chan
