
> > > Does looking up by the catalog keys take no cost ?
> > 
> > Obviously there is cost, but doing a lookup only on demand, has got to be
> > cheaper in the long run than including the entire column definition in the
> > message whether it's wanted or not?
> 
> So if there are 100 fields, should we ask the backend 
> the column name 100 times ?

Also doesn't the planner/executor already have all needed info available ?
Thus answering from prepare would be a lot cheaper than selecting the descriptor
after prepare (more network roundtrips, parse, plan and execute the descriptor lookup).

If this where at the protocol level, the client could flag what info is wanted,
and thus avoid all unwanted overhead. 

Andreas

Thu, 13 Mar 2003 18:07:27 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Roadmap for FE/BE protocol redesign
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Also doesn't the planner/executor already have all needed info available ?

Not directly, and not necessarily in the form that the client would want
it in (eg, converting type OID to type name isn't free).  I don't care
to load either the backend or the protocol down with the responsibility
for offering every piece of column data that a client could possibly
want as part of RowDescription.

Besides, elsewhere in this thread we were hearing about how
RowDescription is already too much overhead for some people ;-)

To my mind, the argument in favor of this feature is essentially that
it saves ODBC/JDBC from needing to duplicate the backend's SQL parser;
which is a legitimate concern.  But that doesn't translate to saying
that we should push functionality out of the clients and into the
backend when it wouldn't be in the backend otherwise.  That's just
moving code around on the basis of some rather-shaky arguments about
performance.  And what happens when your client wants something
different from the exact functionality that was pushed to the backend?
You're back to square one.

			regards, tom lane

Thu, 13 Mar 2003 12:32:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Roadmap for FE/BE protocol redesign 
Couldn't it be done optionally, so the clients that want the info pay the
price and those that don't want it get the speed and lower bandwidth?

Just a thought

andrew

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>

> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > Also doesn't the planner/executor already have all needed info available
?
>
> Not directly, and not necessarily in the form that the client would want
> it in (eg, converting type OID to type name isn't free).  I don't care
> to load either the backend or the protocol down with the responsibility
> for offering every piece of column data that a client could possibly
> want as part of RowDescription.
>
> Besides, elsewhere in this thread we were hearing about how
> RowDescription is already too much overhead for some people ;-)
>
> To my mind, the argument in favor of this feature is essentially that
> it saves ODBC/JDBC from needing to duplicate the backend's SQL parser;
> which is a legitimate concern.  But that doesn't translate to saying
> that we should push functionality out of the clients and into the
> backend when it wouldn't be in the backend otherwise.  That's just
> moving code around on the basis of some rather-shaky arguments about
> performance.  And what happens when your client wants something
> different from the exact functionality that was pushed to the backend?
> You're back to square one.
>
> regards, tom lane


Thu, 13 Mar 2003 14:40:16 -0500
"Andrew Dunstan" <andrew@dunslane.net>
Re: Roadmap for FE/BE protocol redesign 