Libpq copy speedup patch attached. No input buffer logic involved, just
removing the expensive PQconsumeInput call per putCopyData call, and leaving
parseInput as is, as discussed before.
Alon.
libpq_copy.patch
Description: Binary data
---(end of
Hi,
Attached is a patch which adds --quiet and --q option to initdb. I
personally needed this option while writing a document and taking
screenshot :) It only shows the error and warning messages, as well as
the last lines.
I've updated the docs. Regression tests pass.
This is my first patch
On Wed, 2006-01-25 at 16:08 +0200, Devrim GUNDUZ wrote:
Hi,
Attached is a patch which adds --quiet and --q option to initdb. I
personally needed this option while writing a document and taking
screenshot :) It only shows the error and warning messages, as well as
the last lines.
I've
Hi Andrew,
On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
What's wrong with just sending stdout to /dev/null? If that eats error
messages too then we should probably fix initdb to send those to
stderr.
We have the same options with reindexdb, for example. I think a command
line
Hi,
On Wed, 2006-01-25 at 17:22 +0200, Devrim GUNDUZ wrote:
On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
What's wrong with just sending stdout to /dev/null? If that eats
error
messages too then we should probably fix initdb to send those to
stderr.
We have the same options
Devrim GUNDUZ wrote:
We have the same options with reindexdb, for example.
reindexdb and friends inherited that option from psql. On a green
field, they probably wouldn't have it. psql has more complex
semantics, so it's not clear whether that's the same thing.
I think a command line
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space
Hi,
On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
I was playing with 8.2 RPM init script and thought that instead of
directing the output to /dev/null, it
Peter Eisentraut wrote:
Devrim GUNDUZ wrote:
We have the same options with reindexdb, for example.
reindexdb and friends inherited that option from psql. On a green
field, they probably wouldn't have it. psql has more complex
semantics, so it's not clear whether that's the same thing.
Hi,
On Wed, 2006-01-25 at 16:32 +0100, Peter Eisentraut wrote:
I think a command line options is better and required.
I think we need more proof of that than a use case involving taking
screen shots.
I've just explained my points as a reply to Tom's mail.
Regards,
--
The PostgreSQL
Devrim GUNDUZ wrote:
Hi,
On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
I was playing with 8.2 RPM init script and thought that instead of
Applied.
---
Bruce Momjian wrote:
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I think this is what Andrus is seeing:
test= CREATE TABLE foo (n numeric(9,3));
CREATE TABLE
test= INSERT INTO foo
Bruce Momjian pgman@candle.pha.pa.us writes:
Devrim GUNDUZ wrote:
Hi,
On Wed, 2006-01-25 at 11:28 -0500, Tom Lane wrote:
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Attached is a patch which adds --quiet and --q option to initdb.
Why is this a good idea?
I was playing with
Greg Stark [EMAIL PROTECTED] writes:
I always wondered why the Redhat init scripts thought it was a clever idea to
redirect the output to /dev/null. It seems like a pessimal user interface
choice. Every time I have to work with a Redhat machine where Postgres isn't
starting up the first thing
I guess I was thinking that the multiple iterations allow for easier
pinpointing of noise on the system. I think I remember originally
writing this during an episode where successive runs of pgbench were
yielding wildly different results, and I wound up wanting an easy way
to detect this
Alon Goldshuv [EMAIL PROTECTED] writes:
Libpq copy speedup patch attached. No input buffer logic involved, just
removing the expensive PQconsumeInput call per putCopyData call, and leaving
parseInput as is, as discussed before.
Applied (with a better comment) to HEAD and 8.1 branches.
The enclosed patch substantially improves large sort performance, in the
general case
cvstip: elapsed 5693 sec, CPU 196 sec
patch: elapsed 4132 sec, CPU 90 sec
The patch implements dynamically increasing number of logical tapes when
sufficient memory is available to make that efficient. cvstip
Joachim Wieland [EMAIL PROTECTED] writes:
FWIW, I append the patch I've done a few weeks ago. It adds an inettocidr
cast function.
I've incorporated this code into the INET cleanup patch just committed.
Thanks!
regards, tom lane
---(end of
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks
memory in the executor's per-query memory context. It also inefficient:
it invokes get_call_result_type() and TupleDescGetAttInMetadata() for
every call to return_next, rather than invoking them once (per PL/Perl
function call)
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Attached is a revised patch. It became very simple, but I worry that
one magic number (BUFFERS_PER_ABSORB) is still left.
Have you checked that this version of the patch fixes the problem you
saw originally?
20 matches
Mail list logo
