Re: Any better plan for this query?..
От | Dimitri |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 5482c80a0905120029s78d5595dp83a659238cd0cbea@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Any better plan for this query?..
|
Список | pgsql-performance |
>> So, why I don't use prepare here: let's say I'm testing the worst >> stress case :-) Imagine you have thousands of such kind of queries - >> you cannot prepare all of them! :-) > > Thousands? Surely there'll be a dozen or three of most common queries, > to which you pass different parameters. You can prepare thoseu Ok, and if each client just connect to the database, execute each kind of query just *once* and then disconnect?.. - cost of prepare will kill performance here if it's not reused at least 10 times within the same session. Well, I know, we always can do better, and even use stored procedures, etc. etc. > >> Now, as you see from your explanation, the Part #2 is the most >> dominant - so why instead to blame this query not to implement a QUERY >> PLANNER CACHE??? - in way if any *similar* query is recognized by >> parser we simply *reuse* the same plan?.. > > This has been discussed in the past, but it turns out that a real > implementation is a lot harder than it seems. Ok. If I remember well, Oracle have it and it helps a lot, but for sure it's not easy to implement.. Rgds, -Dimitri
В списке pgsql-performance по дате отправления: