Re: Binary tx format for an array?
От | Dave Cramer |
---|---|
Тема | Re: Binary tx format for an array? |
Дата | |
Msg-id | 847D8099-EA4C-4692-A01C-7A18B3280D68@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: Binary tx format for an array? (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Binary tx format for an array?
Re: Binary tx format for an array? |
Список | pgsql-jdbc |
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 >
В списке pgsql-jdbc по дате отправления: