Обсуждение: 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