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 orig
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) and
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 br
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 r
"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.
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 an
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 t
Bruce Momjian 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 wi
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
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 inst
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
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 t
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/nul
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
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 opti
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
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 op
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
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 to
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 broadcast)-
20 matches
Mail list logo
