Re: Postgres chooses slow query plan from time to time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kristjan Mustkivi <sonicmonkey@xxxxxxxxx> writes:
> Both are of type varchar(30).

Ah, right, you showed that back at the top of the thread.

> So is this something odd: Filter: (((product_code)::text = ($1)::text)
> AND ((balance_type)::text = ($4)::text)) ?

Yes, that is very darn odd.  When I try this I get:

regression=# create table foo(f1 varchar(30), f2 int, primary key (f2,f1));
CREATE TABLE

regression=# explain select * from foo where f2 = 11 and f1 = 'bar';
                                QUERY PLAN                                
--------------------------------------------------------------------------
 Index Only Scan using foo_pkey on foo  (cost=0.15..8.17 rows=1 width=37)
   Index Cond: ((f2 = 11) AND (f1 = 'bar'::text))
(2 rows)

regression=# explain select * from foo where f2 = 11 and f1::text = 'bar';
                                QUERY PLAN                                
--------------------------------------------------------------------------
 Index Only Scan using foo_pkey on foo  (cost=0.15..8.17 rows=1 width=37)
   Index Cond: ((f2 = 11) AND (f1 = 'bar'::text))
(2 rows)

regression=# prepare p as select * from foo where f2 = $1 and f1 = $2;
PREPARE

regression=# explain execute p(11,'bar');
                                QUERY PLAN                                
--------------------------------------------------------------------------
 Index Only Scan using foo_pkey on foo  (cost=0.15..8.17 rows=1 width=37)
   Index Cond: ((f2 = 11) AND (f1 = 'bar'::text))
(2 rows)

-- repeat a few times till it switches to a generic plan ...

regression=# explain execute p(11,'bar');
                                QUERY PLAN                                
--------------------------------------------------------------------------
 Index Only Scan using foo_pkey on foo  (cost=0.15..8.17 rows=1 width=37)
   Index Cond: ((f2 = $1) AND (f1 = $2))
(2 rows)

Note the lack of any visible cast on the varchar column, in each one of
these queries, even where I tried to force one to appear.  There is
something happening in your database that is not happening in mine.

My mind is now running to the possibility that you've got some extension
that creates an "=" operator that is capturing the syntax.

			regards, tom lane





[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux