Обсуждение: Weird performance drop
Hi all. I'm running PostgreSQL v8.1.8 (under Linux Ubuntu). A function body is written as "language sql stable". There is just a select for a search in a view with two arguments to do the search. The search is done with equality comparisons. Both the function call and the select alone run very fast thanks to the indexes on the right columns I presume. Then I create a twin function where part of the comparison is done with the "like" operator on one of the very same columns as the previous case. While the function call is very slow, the select alone runs almost as fast as in the case of equality comparison. 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. Any hint? -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]
> From: pgsql-performance-owner@postgresql.org > [mailto:pgsql-performance-owner@postgresql.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
On Friday 30 March 2007 01:12 Dave Dutcher wrote: > > From: pgsql-performance-owner@postgresql.org > > [mailto:pgsql-performance-owner@postgresql.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 Is there any "workaround"? In my opinion the later the query planner decisions are taken the more effective they can be. It could be an option for the function (body) to delay any query planner decision. -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]
> From: pgsql-performance-owner@postgresql.org > [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of > Vincenzo Romano > > Is there any "workaround"? > > In my opinion the later the query planner decisions are taken the more > effective they can be. > It could be an option for the function (body) to delay any > query planner > decision. I think a possible workaround is to use a plpgsql function and the execute statement. The docs will have more info. Dave
On Friday 30 March 2007 16:34 Dave Dutcher wrote: > > From: pgsql-performance-owner@postgresql.org > > [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of > > Vincenzo Romano > > > > Is there any "workaround"? > > > > In my opinion the later the query planner decisions are taken the more > > effective they can be. > > It could be an option for the function (body) to delay any > > query planner > > decision. > > I think a possible workaround is to use a plpgsql function and the execute > statement. The docs will have more info. > > Dave Aye sir. It works. There's not much details into the documentation but the real point is that the execute command of the PLPg/SQL actually says the DB to delay the query planning process as late as possible, I have also managed to build search functions at runtime using the execute command with a dynamically built text variable. Complex, error prone but really fast. -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]