Re: force re-planning of prepared statements?
От | pgdba@hush.com |
---|---|
Тема | Re: force re-planning of prepared statements? |
Дата | |
Msg-id | 20081230152436.DE3D720040@smtp.hushmail.com обсуждение исходный текст |
Ответ на | force re-planning of prepared statements? (pgdba@hush.com) |
Ответы |
Re: force re-planning of prepared statements?
|
Список | pgsql-php |
All my data has been fully vacuumed and analyzed, so that isn't the problem. The problem is specifically that the incorrect plan is being selected, and I think that that is due to the re-use of a sub- optimal plan. On Mon, 29 Dec 2008 16:47:10 -0800 V S P <toreason@fastmail.fm> wrote: >Hi, >I do not have an answer for you > >but, it is my understanding that >a) PHP drops the DB connection for every HTTP request >and then creates a new one (unless a proxy is used) >That means that prepare statement has a perfromance benefit >if the same SQL is used more than once per session > >b) if prepare by itself takes long, than may be analyzing >tables/updating >statistics/vaccuming at least the tables involved in the query >might >help > >c) if b) does not help -- personally I would think that the >problem >is somewhere outside the 'prepare' call (unless there is a PG bug >in >that >functionality on that version of the server) > > > > >On Mon, 29 Dec 2008 14:17:05 -0800, pgdba@hush.com said: >> Hi all, I am experiencing some performance issues that I think >are >> stemming from the PDO prepared statements functions. >> >> I have a pretty simple query that runs: >> >> - sub-second when issued from the command line (not prepared) >> >> - takes 200+ seconds when run from the command line inside a >> prepared statement (eg. >> http://www.postgresql.org/docs/8.2/interactive/sql-prepare.html) >> >> - takes over 200s when run from our application, within the pdo >> prepared functions >> >> - runs sub-second from our application if I prepend the query >with >> "explain analyze" and looking at the resulting plan, it shows >the >> same plan as when it runs quickly from the command line. >> >> postgresql 8.2.11, php 5.2.1 >> >> What are my options here? I would like to continue to use bind >> variables to prevent sql injection, but I'd like to force a plan >re- >> parse for every single query. >> >> Any ideas? >> >> >> -- >> Click to become a massage therapist and work for yourself. >> >http://tagline.hushmail.com/fc/PnY6qxsbda5xAD52Aya1On7VD40YOQA3qlB2 >S2RuRhpQuc9Grmy1V/ >> >> >> -- >> Sent via pgsql-php mailing list (pgsql-php@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-php >-- > V S P > toreason@fastmail.fm > >-- >http://www.fastmail.fm - Access all of your messages and folders > wherever you are -- Click for free info on getting an MBA, $200K/ year potential. http://tagline.hushmail.com/fc/PnY6qxsZwTcf7Oemn5WzFssWfYRzs4nJk5s2I9IYZS8jYesUJITCb/
В списке pgsql-php по дате отправления: