Thread: PREPARE code notes
Probably nothing important, but I saw it insrc/backend/commands/prepare.c: 1/ ExecuteQuery() (line 110). Why is needful use copyObject()? The PostgreSQL executor modify query planns? I think copyObject()is expensive call. 2/ Lines 236 -- 245. Why do you "check for pre-existing entry of same name" if you create hash table? I think better isuse "else" for this block of code and check it only if hash table already exist.3/ Last is cosmetic: see line 404,what happen if memory context is not valid? :-) (maybe use some elog() call) Thanks Karel -- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Karel Zak <zakkr@zf.jcu.cz> writes: > 1/ ExecuteQuery() (line 110). Why is needful use copyObject()? The > PostgreSQL executor modify query planns? Yes, and yes. Unfortunately. > 2/ Lines 236 -- 245. Why do you "check for pre-existing entry of > same name" if you create hash table? I think better is use "else" > for this block of code and check it only if hash table already > exist. The code reads more cleanly as-is; changing it as you suggest would create an unnecessary interdependency between two logically distinct concerns. > 3/ Last is cosmetic: see line 404, what happen if memory context > is not valid? :-) (maybe use some elog() call) Or just get rid of the MemoryContextIsValid test --- it shouldn't ever not be valid. Not very important though. regards, tom lane
On Mon, Sep 09, 2002 at 11:51:08AM -0400, Tom Lane wrote: > Karel Zak <zakkr@zf.jcu.cz> writes: > > 1/ ExecuteQuery() (line 110). Why is needful use copyObject()? The > > PostgreSQL executor modify query planns? > > Yes, and yes. Unfortunately. Hmm, it's bad. Is there any way to "fix" executor? Maybe in farfuture we will save to cache all planns and copyObject() isnotperformance winning. > > 2/ Lines 236 -- 245. Why do you "check for pre-existing entry of > > same name" if you create hash table? I think better is use "else" > > for this block of code and check it only if hash table already > > exist. > > The code reads more cleanly as-is; changing it as you suggest would > create an unnecessary interdependency between two logically distinct > concerns. I don't believe :-) Karel -- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Karel Zak <zakkr@zf.jcu.cz> writes: > On Mon, Sep 09, 2002 at 11:51:08AM -0400, Tom Lane wrote: >>> PostgreSQL executor modify query planns? >> >> Yes, and yes. Unfortunately. > Hmm, it's bad. Is there any way to "fix" executor? It should be fixed IMHO ... but it'll be a major restructuring and it's difficult to justify spending the time ... regards, tom lane