Greg Smith wrote:
Heikki's great summary helps (I think the one piece I was screwing up
is covered there), and Pavan's comments adds some useful bits. The
still missing part is how to make a real branch to work in, which is
much easier to work with once you figure out how to do it than eit
Afaik Tom hadn't finished his patch when I was testing things, so I
don't know. But we're in the process of benchmarking a new system (dual
quad-core Xeon) and we'll have a look at how it performs in the postgres
8.2dev we used before, the stable 8.2.4 and a fresh HEAD-checkout (which
we'll cal
Andrew Dunstan wrote:
What would making a branch actually do for you? The only advantage I can
see is that it will give you a way of checkpointing your files. As I
remarked upthread, I occasionally use RCS for that. But mostly I don't
actually bother. I don't see how you can do it reasonably of
Hi guys of the pgsql-hackers list.
I've received a bug report on the OLE DB list, which I suspect is
actually a server bug. The correspondence so far is listed further on,
but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
the binary interface), and server version 8.1.9 on Wind
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> I don't really want to do this. I really want my users
> to be able to use the COPY statement without worrying
> about whether they are copying into a table or a view.
But ... but ... the proposed feature entirely fails to achieve that.
Copying into an
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> On 05/18/2007 08:59:11 PM, Tom Lane wrote:
>> I'd like to see something that emphasizes review and feedback at the
>> stages of germinal idea, rough functional spec, implementation
>> concept,
> Speaking as a larval Postgres hacker I have trouble asking
Shachar Shemesh wrote:
> Hi guys of the pgsql-hackers list.
>
> I've received a bug report on the OLE DB list, which I suspect is
> actually a server bug. The correspondence so far is listed further on,
> but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
> the binary interface
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> I've received a bug report on the OLE DB list, which I suspect is
> actually a server bug. The correspondence so far is listed further on,
> but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
> the binary interface), and server versi
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> I'll reiterate - the problem is not that PG is exporting the internal
> ARM FP format. The problem is that the server is exporting the internal
> ARM FP format when the server is ARM, and the IEEE format when the
> server is Intel. It's not the format,
Stefan Kaltenbrunner wrote:
> Shachar Shemesh wrote:
>
>> Hi guys of the pgsql-hackers list.
>>
>> I've received a bug report on the OLE DB list, which I suspect is
>> actually a server bug. The correspondence so far is listed further on,
>> but, in a nutshell, user runs an OLE DB client on wind
Tom Lane wrote:
> Shachar Shemesh <[EMAIL PROTECTED]> writes:
>
>> I've received a bug report on the OLE DB list, which I suspect is
>> actually a server bug. The correspondence so far is listed further on,
>> but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
>> the binary i
Tom Lane wrote:
> Shachar Shemesh <[EMAIL PROTECTED]> writes:
>
>> I'll reiterate - the problem is not that PG is exporting the internal
>> ARM FP format. The problem is that the server is exporting the internal
>> ARM FP format when the server is ARM, and the IEEE format when the
>> server is I
Shachar Shemesh wrote:
Tom Lane wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
I'll reiterate - the problem is not that PG is exporting the internal
ARM FP format. The problem is that the server is exporting the internal
ARM FP format when the server is ARM, and the IEEE format when the
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I agree in principle that the wire protocol should be
> platform-independent.
The *TEXT* format is for that. The problem here is that Shachar is
insisting on using binary format in a context where it is inappropriate.
Binary format has other goals
On Sat, 19 May 2007, Andrew Dunstan wrote:
What would making a branch actually do for you? The only advantage I can see
is that it will give you a way of checkpointing your files.
Exactly. It's not as bad now, but when I was getting started there were
lots of times I got something working an
Tom Lane wrote:
> Binary format has other goals that are not always compatible with 100%
> platform independence --- that's unfortunate, sure, but it's reality.
>
Maybe the misunderstanding is mine. What are the goals for the binary
format?
Shachar
---(end of broadcast)
Heikki Linnakangas wrote:
>> But sometimes, like now, PG puts me in an impossible position. You are
>> essentially telling me "you will get the numbers in an unknown format,
>> you will not have any way of knowing whether you got them in a strange
>> format or not, nor will you have any docs on wha
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Binary format has other goals that are not always compatible with 100%
>> platform independence --- that's unfortunate, sure, but it's reality.
>>
> Maybe the misunderstanding is mine. What are the goals for the binary
> format?
Wel
Shachar Shemesh wrote:
Perhaps OLE is trying to use binary instead of text transmission of
data?
Of course it does. That's what the OLE DB specs say. Said so in my
original email.
Why the heck do the OLE DB specs care about the internals of the
client-server prototocol? It is docum
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> Is it not possible to use text
>> format in OLE DB, for floating points?
> It is impossible to use text format for just floating point. I often
> don't know in advance what type the result is going to be.
Sure it's "possib
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I do recall someone telling me that text mode transfer could actually be
> faster than binary, somewhat to their (and my) surprise.
Seems a bit improbable --- what was their test case?
The only such situation that comes to mind is that some values are
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I do recall someone telling me that text mode transfer could actually be
faster than binary, somewhat to their (and my) surprise.
Seems a bit improbable --- what was their test case?
No idea - this was idle chat on IRC
I've been thinking about what it will take to solve the problem noted here:
http://archives.postgresql.org/pgsql-performance/2007-05/msg00325.php
which briefly is that 8.2 is really bad at estimating the number of
rows returned by locutions like
SELECT ... FROM
tab1 LEFT JOIN tab
Tom Lane wrote:
> Sure it's "possible". Send a Parse command, ask for Describe Statement
> output, then specify the column formats as desired in Bind. Now this
> does imply an extra server round trip, which might be annoying if your
> client code doesn't have another reason to need to peek at Des
Tom Lane wrote:
> Obviously, if you are transporting the dump across platforms then that
> may be an impossibility. In that case you use a text dump and accept
> that you get an approximation.
That's something that I've been meaning to ask about, but you all
seemed so sure of yourself. What you a
Andrew Dunstan wrote:
> Why the heck do the OLE DB specs care about the internals of the
> client-server prototocol? It is documented fairly clearly that text is
> the only portable way to transfer data.
>
Is it?
> Perhaps we need to expand this sentence in the docs: "Keep in mind that
> bina
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, not unless you can make the case why this handles NaNs and
>> denormalized numbers compatibly across platforms...
>>
> NaNs and infinite (plus and minus) should not be a problem.
Really? Need I point out that these concepts, le
Shachar Shemesh wrote:
Even the original sentence does not describe the problem we're seeing
here. It does not mention cross platform incompatibility.
That's why I suggested it should be improved.
The COPY docs are probably more correct: "The BINARY key word causes all
data to be stored
Tom Lane wrote:
> Shachar Shemesh <[EMAIL PROTECTED]> writes:
>
>> Tom Lane wrote:
>>
>>> No, not unless you can make the case why this handles NaNs and
>>> denormalized numbers compatibly across platforms...
>>>
>>>
>> NaNs and infinite (plus and minus) should not be a problem.
>>
29 matches
Mail list logo
