Re: [HACKERS] Speedups
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Speedups |
Дата | |
Msg-id | 199803051635.LAA15086@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Speedups (ocie@paracel.com) |
Список | pgsql-hackers |
> I don't think it is so much a question of syntax as it is a question > of what we do in the backend. Suppose I create a stored query in SQL. > We already store the SQL source for this in the database, right? So > when it comes time to execute the query, we take this SQL and execute > it as if the user had entered it directly. What I am proposing would > be to basically store the compiled query plan as well. > > I do see a couple sticky points: > > We would need some information about which variables are to be > substituted into this query plan, but this should be fairly > straightforward. > > Some querys may not respond well to this, for example, if a table had > an index on an integer field f1, this would probably be the best way > to satisfy a select where f1<10. But if this were in a query as f1<x, > then a sufficiently high value of x might make this not such a good > way to run the query. I haven't looked into this, but I would assume > that the optimizer relies on the specific values in such cases. I have thought about this. If we take a query string, remove all quoted constants and numeric constants, we can automatically split apart the query from the parameters. We can then look up the non-parameter query in our cache, and if it matches, replace the new contants with the old and run the query. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: