Re: Compile Failue on win32 - pipe.c using ereport

You are right! (goes away to sign up....)

Merlin Moncure wrote:

>
>p.s. this probably belongs on win32 hackers list.
>
>Merlin
>  
>

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

ecpg glitch in CVS tip

I'm seeing this:

make[4]: Entering directory `/home/postgres/pgsql/src/interfaces/ecpg/ecpglib'
...
gcc -O1 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations  -fpic -DFRONTEND
-I../../../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq
-I../../../../src/port -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED   -c -o descriptor.o descriptor.c
descriptor.c: In function `ECPGset_desc':
descriptor.c:460: warning: assignment from incompatible pointer type
descriptor.c:438: warning: unused variable `last_di'
...

Looks like that last patch needs a bit o' work yet ...

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

suggestion: set default statistics to 100 for numerics

Seeing how small storage for a number type is compared to a text type, 
and seeing how they tend to be queried on a lot, shouldn't it be 
reasonable for the default stats number for numerics to be 100 instead 
of 10?

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Adding column comment to information_schema.columns

Hi all,

Not sure how worthwhile others will find this small patch (to CVS HEAD), 
but we found it useful.  It adds the column comments to the 
information_schema.columns view.

Hope it's useful.



Regards and best wishes,

Justin Clift

*** information_schema.sql.orig	2004-07-01 11:59:26.000000000 +1000
--- information_schema.sql	2004-07-01 12:33:01.000000000 +1000
***************
*** 442,448 ****

             CAST(null AS cardinal_number) AS maximum_cardinality,
             CAST(a.attnum AS sql_identifier) AS dtd_identifier,
!            CAST('NO' AS character_data) AS is_self_referencing

      FROM (pg_attribute a LEFT JOIN pg_attrdef ad ON attrelid = adrelid AND attnum = adnum),
           pg_class c, pg_namespace nc, pg_user u,
--- 442,450 ----

             CAST(null AS cardinal_number) AS maximum_cardinality,
             CAST(a.attnum AS sql_identifier) AS dtd_identifier,

compile warnings

In addition to the ecpg warnings mentioned by Tom, I'm also seeing 
compile warnings wrt plpython:

make[3]: Entering directory `/opt/src/pgsql-cvs/pgsql-7.5/src/pl/plpython'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes 
-Wmissing-declarations -fpic -I. -I/usr/include/python2.3 
-I../../../src/include -D_GNU_SOURCE  -I/usr/include/et  -c -o 
plpython.o plpython.c -MMD
In file included from /usr/include/python2.3/Python.h:8,
                  from plpython.c:58:
/usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from /usr/include/stdio.h:28,
                  from ../../../src/include/c.h:60,
                  from ../../../src/include/postgres.h:48,
                  from plpython.c:37:
/usr/include/features.h:131:1: warning: this is the location of the 
previous definition
ar crs libplpython.a plpython.o

Joe

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Performance with new nested-xacts code

I was all set to launch into a diatribe about the half dozen performance
issues I think we *must* fix in the new nested-transactions code, and
thought I'd back it up by citing some pgbench numbers.  So I ran pgbench
runs using yesterday's CVS tip and current.  I had to fix a small memory
leak before I could get through pgbench -i at all , but after that I
found that today's tip seems a good 10% faster than yesterday's.

This brought me up short.  I sure as heck do not see anything in that
patch that would represent a performance gain over before, especially
not in the very vanilla-flavor cases exercised by pgbench.  Do you see
an explanation?  I'm a bit worried that we've managed to dike out some
essential operation or other...

Can anyone else reproduce these results?  The test case I'm using is
	pgbench -i -s 10 bench
followed by repeated
	pgbench -c 5 -t 1000 bench
I've built PG with --enable-debug and --enable-cassert, and am running
with -F (fsync off) but otherwise absolutely factory-stock
postgresql.conf.  The hardware is a not-so-new-anymore Dell P4 with
run-of-the-mill IDE disk drive, running RHL 8.0.  Obviously none of this
is tuned at all, but the question is why did CVS tip get faster when it
should by rights be slower.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Re: Adding column comment to information_schema.columns

On Thu, 1 Jul 2004, Justin Clift wrote:

> but we found it useful.  It adds the column comments to the 
> information_schema.columns view.

Doesn't the specification say exactly what columns should exist?

Lots of things in the old system tables are not visible in the
information_schema because of this. Not that I think a comment column
would hurt, but anyway.

--

-- 
/Dennis Björklund

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Re: Performance with new nested-xacts code

Hi Tom,

As requested - although the results are all over the place... 
One interesting factor in these tests is that the max tps without
the new code was 74.7, with the new code, 85.8.

This is a Sony Laptop, slow IDE disk, Fedora Core 2

[grant <at> localhost pgsql-HEAD]$ uname -a
Linux localhost.localdomain 2.6.6-1.435 #1 Mon Jun 14 09:09:07 EDT 2004 i686 
i686 i386 GNU/Linux

./bin/postmaster -F

HTH.

Regards,
Grant

-- PRE NESTED XACTS
[grant <at> localhost pgbench]$ ./pgbench -c 5 -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 5
number of transactions per client: 1000
number of transactions actually processed: 5000/5000
tps = 74.632059 (including connections establishing)
tps = 74.710309 (excluding connections establishing)

Re: Performance with new nested-xacts code

On Thu, Jul 01, 2004 at 12:21:55AM -0400, Tom Lane wrote:
> I was all set to launch into a diatribe about the half dozen performance
> issues I think we *must* fix in the new nested-transactions code,

I completely agree, of course.

> This brought me up short.  I sure as heck do not see anything in that
> patch that would represent a performance gain over before, especially
> not in the very vanilla-flavor cases exercised by pgbench.  Do you see
> an explanation?  I'm a bit worried that we've managed to dike out some
> essential operation or other...

Nope, nothing; in fact, I think the only thing that changed in the
normal (no subxacts) code path are the tqual.c tests, and those ought to
be more expensive than before, not less ...

The only thing that changed somewhat is the new GUC code you wrote, but
I doubt that could account for a 10% performance increase.

> Can anyone else reproduce these results?  The test case I'm using is
> 	pgbench -i -s 10 bench
> followed by repeated
> 	pgbench -c 5 -t 1000 bench

I measure the same in 7 runs:

    Yesterday   Today
    241.37      243.02
    215.3       228.58
    235.13      225.57

possibly updating techdocs; mysql2pgsql on gborg

hi
,
I am on a mission to simply keep a starving project off the ground by updating an old mysql->pgsql perl
conversion script which does its conversion very differently from the one under contrib/.  There is an old
link to 
http://www.rot13.org/~dpavlin/sql.html
on techdocs under the section

Converting from other Databases to PostgreSQL

in a section which was apparently "Last updated 7th September 2002"

If anybody still has access to that page, the project has moved to gborg specifically 
over to

http://gborg.postgresql.org/project/mysql2psql/projdisplay.php

where a new version of the perl conversion script is located.

"Can the link be updated?"  

The version on gborg has cvs access and multiple developers, and is being maintained bymyself.  I would be
amazed if nobody else tweaked it in its weak spots.

thanks,

joe speigle

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command