Re: [HACKERS] Cache query (PREPARE/EXECUTE)
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Cache query (PREPARE/EXECUTE) |
Дата | |
Msg-id | 5824.951345647@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Cache query (PREPARE/EXECUTE) (wieck@debis.com (Jan Wieck)) |
Ответы |
Re: [HACKERS] Cache query (PREPARE/EXECUTE)
|
Список | pgsql-hackers |
wieck@debis.com (Jan Wieck) writes: > But I think one context per plan is still better, since first > there is no leakage/multiref problem. Second, there is a > performance difference between explicitly pfree()'ing > hundreds of small allocations (in freeObject() traverse), and > just destroying a context. Agreed, though one would hope that performance of cache flushes is not a major consideration ;-). What I find attractive about going in this direction is the idea that we could get rid of freeObject() entirely, and eliminate that part of the work involved in changing node definitions. > Then again, copyObject/freeObject must be fixed WRT > leakage/multiref anyway. Not if we decide to get rid of freeObject, instead. I think that a little work would have to be done to support efficient use of large numbers of contexts, but it's certainly doable. This path seems more attractive than trying to make the world safe for freeObject of arbitrary node trees. regards, tom lane
В списке pgsql-hackers по дате отправления: