Re: Performance problems with prepared statements
От | Theo Kramer |
---|---|
Тема | Re: Performance problems with prepared statements |
Дата | |
Msg-id | 1192176335.2470.20.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Performance problems with prepared statements (Andrew - Supernews <andrew+nonews@supernews.com>) |
Ответы |
Re: Performance problems with prepared statements
|
Список | pgsql-performance |
On Thu, 2007-10-11 at 18:28 +0000, Andrew - Supernews wrote: > On 2007-10-10, Theo Kramer <theo@flame.co.za> wrote: > > When doing a 'manual' prepare and explain analyze I get the following > > > > rascal=# prepare cq (char(12), smallint, integer) as SELECT oid, > > calllog_mainteng, calllog_phase, calllog_self FROM calllog > > WHERE calllog_mainteng = $1 > > AND calllog_phase = $2 > > AND calllog_self < $3 > > OR calllog_mainteng = $1 > > AND calllog_phase < $2 > > ORDER BY calllog_mainteng DESC, > > calllog_phase DESC, > > calllog_self DESC limit 25; > > PREPARE > > When you do this from the application, are you passing it 3 parameters, > or 5? The plan is clearly taking advantage of the fact that the two > occurrences of $1 and $2 are known to be the same value; if your app is > using some interface that uses ? placeholders rather than numbered > parameters, then the planner will not be able to make this assumption. You may just have hit the nail on the head. I use numbered parameters but have $1 to $5 ... let me take a look to see if I can change this. > Also, from the application, is the LIMIT 25 passed as a constant or is that > also a parameter? A constant. > -- Regards Theo
В списке pgsql-performance по дате отправления: