These are the queries I used to get the execution planer use the index scan
instead of the sequential scan:
IF NOT EXISTS (SELECT 1 FROM custom_data WHERE key = old.key) => sequential scan
IF NOT EXISTS (SELECT 1 FROM custom_data WHERE key = old.key LIMIT 1) =>
sequential scan
IF NOT EXISTS (SEL
Guido Niewerth writes:
> And this is the execution plan. It looks like it does a slow sequential scan
> where it´s able to do an index scan:
> 2015-11-02 17:42:10 CET LOG: duration: 5195.673 ms plan:
> Query Text: SELECT NOT EXISTS( SELECT 1 FROM custom_data
> WHERE key = old.
I needed to set up the trigger function again, so here it is:
CREATE OR REPLACE FUNCTION public.fn_trigger_test ()
RETURNS trigger AS
$body$
DECLARE
start TIMESTAMP;
BEGIN
start := timeofday();
IF TG_OP = 'UPDATE' THEN
IF NOT EXISTS( SELECT key FROM custom_data WHERE ke
Guido Niewerth writes:
> As you can see there´s a huge runtime difference between the select query
> used in the trigger function and the one run from the SQL editor.
contrib/auto_explain might be useful in seeing what's going on, in
particular it would tell us whether or not a different plan is
Hello,
I´ve got a table custom_data which essentially contains a number of key/value
pairs. This table holds a large number (about 40M) of records and I need the
distinct keys and values for some reasons. Selecting those distinct data takes
a couple of seconds, so I decided to maintain a separa
