Re: [PATCHES] patch for between symmetric, asymmetric (from TODO)

2005-06-01 Thread Peter Eisentraut
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

Re: [PATCHES] patch for between symmetric, asymmetric (from TODO)

2005-06-01 Thread Tom Lane
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

[PATCHES] dbsize backend integration

2005-06-01 Thread Andreas Pflug
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 ?

[PATCHES] patch - doc for execute into (really)

2005-06-01 Thread Pavel Stehule
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

[PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf

2005-06-01 Thread Andreas Pflug
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

Re: [PATCHES] [ADMIN] Config option log_statement

2005-06-01 Thread Bruce Momjian
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

Re: [PATCHES] O_DIRECT for WAL writes

2005-06-01 Thread Mary Edie Meredith
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

Re: [PATCHES] patch for between symmetric, asymmetric (from TODO)

2005-06-01 Thread Christopher Kings-Lynne
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

Re: [PATCHES] COPY fast parse patch

2005-06-01 Thread Bruce Momjian
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

Re: [PATCHES] O_DIRECT for WAL writes

2005-06-01 Thread Neil Conway
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

Re: [PATCHES] COPY fast parse patch

2005-06-01 Thread Neil Conway
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

Re: [PATCHES] COPY fast parse patch

2005-06-01 Thread Andrew Dunstan
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;

Re: [PATCHES] COPY fast parse patch

2005-06-01 Thread Luke Lonergan
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

Re: [PATCHES] COPY fast parse patch

2005-06-01 Thread Alon Goldshuv
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