Re: 7.4 - FK constraint performance
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ow <oneway_111@yahoo.com>
Cc: pgsql-sql@postgresql.org
Date: 2004-02-13T00:00:25Z
Lists: pgsql-hackers, pgsql-sql
ow <oneway_111@yahoo.com> writes: > --- Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think it must be using a seqscan for the foreign key check query. > 2) prepare foo(my.dint) as > SELECT 1 FROM ONLY "my"."large" x WHERE "small_id" = $1 FOR UPDATE OF x; > explain analyze execute foo(201); > QUERY PLAN > Seq Scan on large x (cost=0.00..1787052.30 rows=7893843 width=6) (actual > time=210566.301..210566.301 rows=0 loops=1) > Filter: ((small_id)::integer = ($1)::integer) > Total runtime: 210566.411 ms Well, there's the smoking gun all right. Why does it think there are going to be 7893843 matching rows!? Could we see the pg_stats row for the large.small_id column? regards, tom lane