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
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
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
> > I do think you and others make it less likely every time you throw up big
> > insoluble problems like above though. As a consequence every proposal has
> > started with big overly-complex solutions trying to solve all these
> incidental
> > issues which never go anywhere instead of simple solut
What I'm interested in is auto-tuning, not necessarily overhauling GUCS,
which happens to be the subject of this thread :-)
Having done a SELECT * FROM pg_settings, all the information you need seems
to be there...
Maybe I'm being over-simplistic here, but the important bit is knowing how
you shoul
Hi there... Configuration autotuning is something I am really interested in.
I have seen this page: http://wiki.postgresql.org/wiki/GUCS_Overhaul and
a couple of emails mentioning this, so I wanted to ask is someone already
on it? If yes, I'd like to contribute.
Ideally, an external little app sho
