"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> The main addition is the addition of a -x option that allows
> specification of a number of successive runs of pgbench for use in
> sanity-checking basic benchmark results to reduce the potential for
> noise in a single run.
What exactly do
I created a version of this a while back for a comparison of 7.4.x to
8.0.x. Now that 8.1.x has come out, I've decided to go ahead and put
it in patch form for potential inclusion in contrib.
The main addition is the addition of a -x option that allows
specification of a number of successiv
I have now tested the patch. It passes regression and the test case Tom
previously posted. Unless there's an objection I will apply it and
backport it in the next few days.
cheers
andrew
I wrote:
I was reminded today of the outstanding issue with plperl setting the
locale on Windows, an
On Sun, Jan 15, 2006 at 09:55:39PM -0800, David Fetter wrote:
> On Mon, Jan 16, 2006 at 12:13:11AM -0500, Neil Conway wrote:
> > On Sun, 2006-01-15 at 20:08 -0800, David Fetter wrote:
> > >
> > > ifdef USE_PGXS
> >
> > The change to $PostgreSQL$ is bogus (perhaps due to the way you
> > setup
> You mean something like
>
> if (input-buffer-not-empty)
> parseInput();
>
> ? This still bothers me a bit since it's a mixing of logic levels;
> PQputCopyData is an output routine, it shouldn't be getting its fingers
> dirty with input buffer contents. I'm willing to tolerate this if it
> can
"Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> I guess that although parseInput is cheap we could still use a conditional
> to see when data was sent and only then call it (without PQconsumeInput)
> instead of calling it every single time PQputCopyData is called. Any
> objection to that?
You mean s
Tom,
>> Here is a patch against today's code 1/24. As discussed in -hackers
>> consumeInput/parse is removed from being called every single time. It's
>> still there for only when the data is sent to the server.
>
> This appears to be the exact same patch you sent before. Did you
> test my sugge
Joachim Wieland <[EMAIL PROTECTED]> writes:
> FWIW, I append the patch I've done a few weeks ago. It adds an inettocidr
> cast function.
I think we need to take two steps back and look at the larger picture:
the INET/CIDR situation is conceptually a mess and it's going to take
more than a localize
"Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> Here is a patch against today's code 1/24. As discussed in -hackers
> consumeInput/parse is removed from being called every single time. It's
> still there for only when the data is sent to the server.
This appears to be the exact same patch you sent b
On Mon, Jan 23, 2006 at 11:30:58PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Patch for testing attached.
> This is an utterly bad idea, because it not only doesn't address the
> problem (ie, confusion about whether inet and cidr are distinct types
> or not), but it masks mistakes in that
This attached patch greatly enhances DBMirror.pl performance.
DBMirror.pl was known to have problems when replicating
bytea columns whose data was binary bytes (non printable).
(E.g. tiff, pdf, jpeg, bzip2, etc...)
Minutes, (or hours) for 500kb columns were not unusual.
There has even been an ef
Here is a patch against today's code 1/24. As discussed in -hackers
consumeInput/parse is removed from being called every single time. It's
still there for only when the data is sent to the server.
Alon.
pq_put_copy_data.patch
Description: Binary data
---(end of broadca
12 matches
Mail list logo
