Pavel Stehule [EMAIL PROTECTED] writes:
I did task from TODO: Add BETWEEN ASYMMETRIC/SYMMETRIC.
this patch is based on Robert's B. Easter work from 2001 year.
http://archives.postgresql.org/pgsql-patches/2001-01/msg00022.php
IIRC, that patch was rejected at the time because of
As a start for a bunch of instrumentation functions that should be
included in the backend as discussed previously, here are the dbsize
functions. The dbsize.c file should go to the usual place,
src/backend/utils/adt.
Regards,
Andreas
? GNUmakefile
? config.log
? config.status
?
Hello
I am sorry, this mail contains doc for execute into
Regards
Pavel Stehule
*** pgsql.old/doc/src/sgml/plpgsql.sgml 2005-04-19 05:55:43.0 +0200
--- pgsql.new/doc/src/sgml/plpgsql.sgml 2005-06-01 19:28:51.0 +0200
***
*** 1251,1263
This patch reenables pg_terminate_backend, allowing (superuser only, of
course) to terminate a backend. As taken from the discussion some weeks
earlier, SIGTERM seems to be used quite widely, without a report of
misbehaviour so while the code path is officially not too well tested,
in practice
Fix applied. It will appear in 8.0.X. Patch attached.
---
S Murthy Kambhampaty wrote:
In postgresql 8.0, create table as ... statements
appear not to logged unless log_statement = 'all' in
postgresql.conf. We are
On Mon, 2005-05-30 at 16:29 +1000, Neil Conway wrote:
On Mon, 2005-05-30 at 10:59 +0900, ITAGAKI Takahiro wrote:
Yes, I've tested pgbench and dbt2 and their performances have improved.
The two results are as follows:
1. pgbench -s 100 on one Pentium4, 1GB mem, 2 ATA disks, Linux 2.6.8
The implementation in this patch has the same problems as all the
previously rejected attempts: it evaluates its arguments twice. You
need to make BETWEEN SYMMETRIC into a separate node type that evaluates
each argument only once.
And that's also been submitted. The problem then is making
Alon Goldshuv wrote:
5) Data integrity and escaping improvements. Treats all characters as data
(unless it's an escaped delim or EOL) and therefore data
integrity is preserved. However, some people that already got
used to the postgres COPY escaping way may want to keep it. They could do so
On Wed, 2005-06-01 at 17:08 -0700, Mary Edie Meredith wrote:
I know I'm late to this discussion, and I haven't made it all the way
through this thread to see if your questions on Linux writes were
resolved. If you are still interested, I recommend read a very good
one page description of
On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
1) The patch includes 2 parallel parsing code paths. One is the regular COPY
path that we all know, and the other is the improved one that I wrote. This
is only temporary, as there is a lot of code duplication
Right; I really dislike the
Neil Conway said:
On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
1) The patch includes 2 parallel parsing code paths. One is the
regular COPY path that we all know, and the other is the improved one
that I wrote. This is only temporary, as there is a lot of code
duplication
Right;
Andrew,
I will be the first to admit that there are probably some very good
possibilities for optimisation of this code. My impression though has been
that in almost all cases it's fast enough anyway. I know that on some very
modest hardware I have managed to load a 6m row TPC line-items
Neil,
Right; I really dislike the idea of having two separate code paths for
COPY. When you say this approach is temporary, are you suggesting that
you intend to reimplement your changes as improvements/replacements of
the existing COPY code path rather than as a parallel code path?
My
13 matches
Mail list logo
