From: Tom Lane <tgl@sss.pgh.pa.us>
To: Guido Niewerth <gniewerth@ocsgmbh.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Slow query in trigger function
In-reply-to: <59f5e6f55a72407bbb521a4b7020c692@EX2k13.ocsnet.local>
References: <d9752446b5164156836d9bb97bacfe58@EX2k13.ocsnet.local>
 <59f5e6f55a72407bbb521a4b7020c692@EX2k13.ocsnet.local>
Comments: In-reply-to Guido Niewerth <gniewerth@ocsgmbh.com>
 message dated "Mon, 02 Nov 2015 16:54:21 +0000"
Date: Mon, 02 Nov 2015 13:10:19 -0500
Message-ID: <7702.1446487819@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Guido Niewerth <gniewerth@ocsgmbh.com> 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.key LIMIT 1 )
>                 Result  (cost=0.09..0.10 rows=1 width=0) (actual time=5195.667..5195.667 rows=1 loops=1)
>                   Output: (NOT $0)
>                   Buffers: shared hit=34 read=351750
>                   InitPlan 1 (returns $0)
>                     ->  Limit  (cost=0.00..0.09 rows=1 width=0) (actual time=5195.662..5195.662 rows=0 loops=1)
>                           Output: (1)
>                           Buffers: shared hit=34 read=351750
>                           ->  Seq Scan on public.custom_data  (cost=0.00..821325.76 rows=9390835 width=0) (actual time=5195.658..5195.658 rows=0 loops=1)
>                                 Output: 1
>                                 Filter: (custom_data.key = $15)
>                                 Buffers: shared hit=34 read=351750

It looks like you're getting bit by an inaccurate estimate of what will be
the quickest way to satisfy a LIMIT query.  In this particular situation,
I'd advise just dropping the LIMIT, as it contributes nothing useful.

(If memory serves, 9.5 will actually ignore constant-LIMIT clauses inside
EXISTS(), because people keep writing them even though they're useless.
Earlier releases do not have that code though.)

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance