On Thu, 2005-06-02 at 00:53 -0400, Alon Goldshuv wrote:
> My thoughts were -- see how the responses are, and if people think
> that this is a better way to go than replace the COPY parsing logic to
> the new one.
If the new approach to parsing can handle all the cases that the old
approach can han
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 tho
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 t
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
>
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 th
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
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
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 th
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
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 a
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
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
EXECUTE statem
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
? dbsize-backen
Hello
This patch contains info about EXECUTE .. INTO statement.
Regards
Pavel Stehule
*** pgsql.old/doc/src/sgml/func.sgml2005-05-23 03:50:01.0 +0200
--- pgsql.new/doc/src/sgml/func.sgml2005-06-01 19:17:08.0 +0200
***
*** 279,284
--- 279,300 ---
Hello
I add doc and removed words symmetric and asymmetric from
keywords. Corrected boolean expression too. This patch don't solve some
problems: multiple evaluation of arguments, but its trivial and work with
bitmap indexes.
Regards
Pavel Stehule
diff -c -r --new-file pgsql.old/src/ba
Pavel Stehule <[EMAIL PROTECTED]> writes:
> Bitmap Heap Scan on fx (cost=12.00..473.00 rows=998 width=4) (actual
> time=0.516..3.855 rows=1035 loops=1)
>Recheck Cond: (((i >= 1) AND (i <= 10)) OR ((i >= 10) AND (i <= 1)))
>-> BitmapOr (cost=12.00..12.00 rows=1000 width=0) (actual
> ti
On Wed, 1 Jun 2005, Tom Lane wrote:
> 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
>
I started wo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> I did task from TODO: Add BETWEEN ASYMMETRIC/SYMMETRIC.
> 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 SYMMETR
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 perfo
Pavel Stehule wrote:
> I did task from TODO: Add BETWEEN ASYMMETRIC/SYMMETRIC.
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
eac
Hello
I did small trivial patch (almost all was written) for storing
result from executing dynamic query into ROW or RECORD variable.
CREATE TABLE fxx(i integer, y integer);
CREATE TYPE fxt AS (i integer, z integer);
CREATE OR REPLACE FUNCTION foo(varchar) RETURNS RECORD AS $$
DECLARE _
Hello
I did task from TODO: Add BETWEEN ASYMMETRIC/SYMMETRIC.
SELECT 2 BETWEEN 1 AND 5 -> true
SELECT 2 BETWEEN 5 AND 1 -> false
SELECT 2 BETWEEN SYMMETRIC 5 AND 1 -> true
this patch is based on Robert's B. Easter work from 2001 year.
http://archives.postgresql.org/pgsql-patches/2001-01
22 matches
Mail list logo
