Re: 7.4 - FK constraint performance - Mailing list pgsql-sql

From Tom Lane
Subject Re: 7.4 - FK constraint performance
Date
Msg-id 24947.1076630425@sss.pgh.pa.us
Whole thread Raw
In response to Re: 7.4 - FK constraint performance  (ow <oneway_111@yahoo.com>)
List 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


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4 - FK constraint performance
Next
From: Bruce Momjian
Date:
Subject: Re: array_lower /array_prepend doubt