Re: Avoiding bad prepared-statement plans.
От | Robert Haas |
---|---|
Тема | Re: Avoiding bad prepared-statement plans. |
Дата | |
Msg-id | 603c8f071002110504yb07519do9dd258c5a0ee6143@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoiding bad prepared-statement plans. (Bart Samwel <bart@samwel.tk>) |
Ответы |
Re: Avoiding bad prepared-statement plans.
|
Список | pgsql-hackers |
On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel <bart@samwel.tk> wrote: > On Thu, Feb 11, 2010 at 13:41, Robert Haas <robertmhaas@gmail.com> wrote: >> >> On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel <bart@samwel.tk> wrote: >> > Anyhow, I have no clue how much time the planner takes. Can anybody >> > provide >> > any statistics in that regard? >> >> It depends a great deal on the query, which is one of the things that >> makes implementing this rather challenging. > > But I guess you can probably expect it to be on the same order for the same > query in generic form and with filled-in parameters? I think so.... but I wouldn't bet the farm on it without testing. > Because that's the > underlying assumption of the "ratio" criterion -- that re-planning with > filled-in parameters takes about as much time as the initial planning run > took. We only want to replan when replanning is relatively cheap compared to execution, so the other assumption is that the planning-to-execution ratio is more or less constant. Whether that's sufficiently true to make the proposed system useful and reliable is not clear to me. ...Robert
В списке pgsql-hackers по дате отправления: