Re: Binary tx format for an array?

On 23-Jun-06, at 8:56 AM, Dave Cramer wrote:

>
> On 23-Jun-06, at 8:47 AM, Michael Guyver wrote:
>
>>> > :) good question, I'm sure I'll stare it in the face soon
>>> enough. At
>>> > the moment I'm labouring under the impression that individual
>>> > parameters can be specified as binary or text.
>>>
>>> Unfortunately this is not possible. :( And one of the reasons that
>>> I've not spent a lot of time on this.
>>
>> Hi Dave,
>>
>> the page Message Formats
>> (http://www.postgresql.org/docs/8.1/static/protocol-message-
>> formats.html)
>> specifies that the bind message should send the following for each
>> parameter:
>>
>> Int16 - The number of parameter format codes that follow (denoted
>> C below). This can be zero to indicate that there are no
>> parameters or
>> that the parameters all use the default format (text); or one, in
>> which case the specified format code is applied to all parameters; or
>> it can equal the actual number of parameters.
>>
>> Int16[C] - The parameter format codes. Each must presently be zero
>> (text) or one (binary).
>>
>> Does your understanding of the spec mean that the Int16[C] must
>> either
>> be an array containg all zero's, or all ones? It reads as though
>> these
>> can be mixed.
>
> Actually, it's the return value that is either/or . It appears that
> input parameters can be mixed.
Hmmm maybe I should read before sending. It appears that both input,
and output can be text. The only catch with output is that you have
to do a describe first to get the types. This may negate any gains on
small result sets, but certainly for large ones it would help.
>
> Tom can they be mixed going in ?
>
> I'm very curious to see how much performance gain can be had here.
> As I said the real gains would be on result sets especially parsing
> date/time, timestamps.
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>