Re: Wrong plan sequential scan instead of an index one [8.2 solved it]

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Wrong plan sequential scan instead of an index one [8.2 solved it]
Date: 2007-04-02 10:40:55
Message-ID: 4610DDB7.5080800@bigfoot.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> Richard Huxton <dev(at)archonet(dot)com> writes:
>> Ah, but it's got no way of knowing what matches you'll get for
>> '%anything%'. There's no easy way to get statistics for matching substrings.
>
> 8.2 actually tries the match on the most-common-values list, if said
> list is big enough (I think the threshold is stats target = 100).
> Not sure if that will help here, though.

I didn't change the stats target and I obtain on a 8.2 engine the result I
was expecting.

test=# explain analyze SELECT COUNT(id) FROM t_oa_2_00_card WHERE pvcp in (select id from l_pvcp where value ilike '%pi%');
QUERY PLAN
- ---------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=163228.76..163228.77 rows=1 width=8) (actual time=23.398..23.398 rows=1 loops=1)
-> Nested Loop (cost=74.71..163020.31 rows=83380 width=8) (actual time=2.237..18.580 rows=7801 loops=1)
-> HashAggregate (cost=2.22..2.41 rows=19 width=4) (actual time=0.043..0.045 rows=1 loops=1)
-> Seq Scan on l_pvcp (cost=0.00..2.17 rows=19 width=4) (actual time=0.028..0.037 rows=1 loops=1)
Filter: (value ~~* '%pi%'::text)
-> Bitmap Heap Scan on t_oa_2_00_card (cost=72.49..8525.04 rows=4388 width=12) (actual time=2.188..9.204 rows=7801 loops=1)
Recheck Cond: (t_oa_2_00_card.pvcp = l_pvcp.id)
-> Bitmap Index Scan on i3_t_oa_2_00_card (cost=0.00..71.39 rows=4388 width=0) (actual time=1.768..1.768 rows=7801 loops=1)
Index Cond: (t_oa_2_00_card.pvcp = l_pvcp.id)
Total runtime: 23.503 ms
(10 rows)

test=# explain analyze SELECT COUNT(id) FROM t_oa_2_00_card WHERE pvcp in (select id from l_pvcp where value ilike 'pi');
QUERY PLAN
- ---------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=38343.44..38343.45 rows=1 width=8) (actual time=23.386..23.387 rows=1 loops=1)
-> Nested Loop (cost=76.52..38299.55 rows=17554 width=8) (actual time=2.246..18.576 rows=7801 loops=1)
-> HashAggregate (cost=2.18..2.22 rows=4 width=4) (actual time=0.041..0.043 rows=1 loops=1)
-> Seq Scan on l_pvcp (cost=0.00..2.17 rows=4 width=4) (actual time=0.026..0.035 rows=1 loops=1)
Filter: (value ~~* 'pi'::text)
-> Bitmap Heap Scan on t_oa_2_00_card (cost=74.33..9519.48 rows=4388 width=12) (actual time=2.198..9.161 rows=7801 loops=1)
Recheck Cond: (t_oa_2_00_card.pvcp = l_pvcp.id)
-> Bitmap Index Scan on i3_t_oa_2_00_card (cost=0.00..73.24 rows=4388 width=0) (actual time=1.779..1.779 rows=7801 loops=1)
Index Cond: (t_oa_2_00_card.pvcp = l_pvcp.id)
Total runtime: 23.491 ms
(10 rows)

I had to lower the random_page_cost = 2.5 in order to avoid the sequential scan on the big table t_oa_2_00_card.

this is a +1 to update our engines to a 8.2.

Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEN237UpzwH2SGd4RAo9yAJ9K7bTa5eEUjvPjk/OcAMgt+AncmQCfbkBH
FlomqoY1ASv3TDkd9L5hgG4=
=ZLS8
-----END PGP SIGNATURE-----

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Peter Schuller 2007-04-02 10:53:55 Re: Scaling SELECT:s with the number of disks on a stripe
Previous Message ramachandra.bhaskaram 2007-04-02 10:35:28 Providing user based previleges to Postgres DB