Re: Nested loop in simple query taking long time

From: Henrik Zagerholm <henke(at)mac(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Nested loop in simple query taking long time
Date: 2007-12-05 22:45:49
Message-ID: 666C3105-FEE3-4927-AB4B-AE5A5F3AA0C9@mac.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


5 dec 2007 kl. 16.25 skrev Tom Lane:

> Henrik Zagerholm <henke(at)mac(dot)se> writes:
>> Usually I can see what is wrong with queries but I can't figure out
>> why this query is slow.
>
> Seems the main problem is here:
>
>> -> Bitmap Index Scan on tbl_archive_idx1
>> (cost=0.00..1150.47 rows=8 width=0) (actual time=1505.456..1505.456
>> rows=86053 loops=16)
>> Index Cond: (tbl_share.pk_share_id =
>> tbl_archive.fk_share_id)
>
> Why is this scan finding so many more rows than the planner expects?
> Perhaps increasing the stats targets on these columns would help it
> make a better estimate.
This is really weird. That tables primary key sequence is at 1220
and the number of rows right now is 139. There have never been that
many rows in tbl_archive. Could the index or stat be really really
corrupt?

Thanks,
Henke

>
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bill Moran 2007-12-05 23:43:01 Re: Avoid huge perfomance loss on string concatenation
Previous Message Erik Jones 2007-12-05 22:29:13 Re: Re-partitioning huge schema