Re: Trying to track down weird query stalls

Поиск
Список
Период
Сортировка
Искать
От
Scott Carey
Тема
Re: Trying to track down weird query stalls
Дата
Msg-id
C5F68B62.3EC2%scott@richrelevance.com
Ответ на
Список
Дерево обсуждения
Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Robert Haas <robertmhaas@gmail.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Robert Haas <robertmhaas@gmail.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Scott Marlowe <scott.marlowe@gmail.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Scott Marlowe <scott.marlowe@gmail.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Robert Haas <robertmhaas@gmail.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Alvaro Herrera <alvherre@commandprompt.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Alvaro Herrera <alvherre@commandprompt.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Alvaro Herrera <alvherre@commandprompt.com>
Re: Trying to track down weird query stalls dan@sidhe.org
Re: Trying to track down weird query stalls Alvaro Herrera <alvherre@commandprompt.com>
Re: Trying to track down weird query stalls Scott Carey <scott@richrelevance.com>

On 3/30/09 2:34 PM, "dan@sidhe.org"  wrote:

>> dan@sidhe.org escribió:
>> 
>>>> So what's the "?" in the query you pasted earlier?
>>> 
>>> The first ? (for architecture) is 1, the second ? (for branchid) is 0.
>>> They both should get passed to Postgres as $1 and $2, respectively,
>>> assuming DBD::Pg does its substitution right. (They're both supposed to
>>> go
>>> in as placeholders)
>> 
>> Right, so how about you reread what I wrote above?
>> 
>> Oh, hmm, so to be more clear: I don't think DBD::Pg is actually sending
>> EXECUTE PREPARE.  You need to do this over psql.
> 
> Fair enough. (And sorry about the mis-read) Next time this occurs I'll try
> and duplicate this in psql. FWIW, a quick read of the C underlying the
> DBD::Pg module shows it using PQexecPrepared, so I'm pretty sure it is
> using prepared statements with placeholders, but double-checking seems
> prudent.
> 
> -Dan
> 

Regardless, its always a good idea to do a manual explain analyze with and
without parameterization in psql if prepared statements are involved.  The
query planner functions very differently with and without them, almost
always with a performance detriment to query execution times when
parameterized.

В списке pgsql-performance по дате отправления
От: Alvaro Herrera
Дата:
От: Matthew Wakeling
Дата:
Сообщение: Re: Very specialised query
FAQ