Re: Weird performance drop

From: "Dave Dutcher" <dave(at)tridecap(dot)com>
To: "'Vincenzo Romano'" <vincenzo(dot)romano(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Weird performance drop
Date: 2007-03-29 23:12:58
Message-ID: 018c01c77257$cb0bd520$2e00a8c0@tridecap.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> From: pgsql-performance-owner(at)postgresql(dot)org
> [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of
> Vincenzo Romano
>
> I thought that the query planner usually did a bad job on
> function bodies
> because they'd appear opaque to it.
> In this case it seems to me that the body is opaque only if I
> use the "like"
> operator.

If you run explain on a query that looks like "select * from a_table where
a_column like 'foo%'" (and you have the appropriate index) you will see that
postgres rewrites the where clause as "a_column >= 'foo' and a_column <
'fop'". I think your problem is that the query is planned when the function
is created, and at that time postgres doesn't know the value you are
comparing against when you use the like operator, so postgres can't rewrite
the query using >= and <. The problem doesn't happen for plain equality
because postgres doesn't need to know anything about what you are comparing
against in order to use equality.

Somebody else can correct me if I'm wrong.

Dave

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Dave Dutcher 2007-03-30 00:15:23 Re: Planner doing seqscan before indexed join
Previous Message Dimitri 2007-03-29 22:15:11 Re: Shared buffers, db transactions commited, and write IO on Solaris