-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Dunstan
Sent: 03 July 2006 23:56
To: PostgreSQL-development
Subject: [HACKERS] buildfarm stats
Sometime in late June the buildfarm passed 50,000 builds reported on.
Here are stats
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
Sent: 04 July 2006 05:53
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] system info functions
(1) The docs claim that pg_get_viewdef() returns the CREATE VIEW
command for view,
Mark,
I don't know how it will exactly works in postgres but my expectations are:
Mark Woodward wrote:
Is there a difference in PostgreSQL performance between these two
different strategies:
if(!exec(update foo set bar='blahblah' where name = 'xx'))
exec(insert into foo(name, bar)
On Tue, Jul 04, 2006 at 11:59:27AM +0200, Zdenek Kotala wrote:
Mark,
I don't know how it will exactly works in postgres but my expectations are:
Mark Woodward wrote:
Is there a difference in PostgreSQL performance between these two
different strategies:
if(!exec(update foo set
Thank you for the feed-back. In fact the risk seems neglibible, but it means that at least I'm not misunderstanding what that code does...Tom Lane [EMAIL PROTECTED] ha scritto: paolo romano <[EMAIL PROTECTED]> writes: My doubts now concern MultixactID wrap-around management. Afaics, it is
Is there a difference in PostgreSQL performance between these two
different strategies:
if(!exec(update foo set bar='blahblah' where name = 'xx'))
exec(insert into foo(name, bar) values('xx','blahblah'); or
In pg, this strategy is generally more efficient, since a pk failing
Dave Page dpage@vale-housing.co.uk writes:
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
Should we change the documentation, or the implementation of
pg_get_viewdef()?
Documentation, unless we want to break apps that use the function.
... such as pg_dump.
I just noticed this warning:
gcc -O -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
-pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic
-DFRONTEND -I. -I../../../src/include -D_GNU_SOURCE
Just wanted to make clear to Hackers that the gates are now open to
include other parameters for CREATE INDEX, as originally requested here:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00851.php
The new WITH (param=value...) syntax could easily be extended to include
a variety of
Simon Riggs [EMAIL PROTECTED] writes:
Just wanted to make clear to Hackers that the gates are now open to
include other parameters for CREATE INDEX, as originally requested here:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00851.php
Just to follow up on the discussion of that
Thanks for the stats Andrew. Out of interest, can you easily tabulate
the number of failures against OS?
Or, more generally, even put a dump of the DB (without personal infos
of course :) somewhere?
Bye, Chris.
PS: and don't say you're running it in MySQL ;)
On Tuesday 04 July 2006 22:14, Chris Mair wrote:
Thanks for the stats Andrew. Out of interest, can you easily tabulate
the number of failures against OS?
Or, more generally, even put a dump of the DB (without personal infos
of course :) somewhere?
Bye, Chris.
PS: and don't say you're
12 matches
Mail list logo
