pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedPerformance issues with compaq server
14+ messages / 9 participants
[nested] [flat]
* Performance issues with compaq server
@ 2002-05-07 22:40 Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-07 23:21 ` Re: Performance issues with compaq server postgres@vrane.com
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-09 12:29 ` Re: Performance issues with compaq server Denis Gasparin <denis@edistar.com>
0 siblings, 3 replies; 14+ messages in thread
From: Samuel J. Sutjiono @ 2002-05-07 22:40 UTC (permalink / raw)
To: pgsql-general@postgresql.org; pgsql-sql
I tried to load data using insert statement to our new database server (Compaq DL580, DL590, DL380 using SCSI driver) but it was very very slow. The database runs on Red Hat Linux 7.2 and PostgreSQL version 7.1.3
Does anybody know any idea to what cause this problem ? or things that I need to look or check (in the config. file)
I appreciate any help.
Regards,
Samuel
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
@ 2002-05-07 23:21 ` postgres@vrane.com
2 siblings, 0 replies; 14+ messages in thread
From: postgres@vrane.com @ 2002-05-07 23:21 UTC (permalink / raw)
To: pgsql-general@postgresql.org
One thing you can try is to use "-F"
switch which will turn off fsync.
$ man postmaster
There are other possibilities however
On Tue, May 07, 2002 at 06:40:32PM -0400, Samuel J. Sutjiono wrote:
> I tried to load data using insert statement to our new database server (Compaq DL580, DL590, DL380 using SCSI driver) but it was very very slow. The database runs on Red Hat Linux 7.2 and PostgreSQL version 7.1.3
>
> Does anybody know any idea to what cause this problem ? or things that I need to look or check (in the config. file)
>
> I appreciate any help.
>
> Regards,
> Samuel
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
@ 2002-05-08 01:25 ` Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2 siblings, 1 reply; 14+ messages in thread
From: Martijn van Oosterhout @ 2002-05-08 01:25 UTC (permalink / raw)
To: Samuel J. Sutjiono <ssutjiono@wc-group.com>; +Cc: pgsql-general@postgresql.org; pgsql-sql
On Tue, May 07, 2002 at 06:40:32PM -0400, Samuel J. Sutjiono wrote:
> I tried to load data using insert statement to our new database server
> (Compaq DL580, DL590, DL380 using SCSI driver) but it was very very slow.
> The database runs on Red Hat Linux 7.2 and PostgreSQL version 7.1.3
>
> Does anybody know any idea to what cause this problem ? or things that I
> need to look or check (in the config. file)
Put them in a trasaction (begin/commit). Without that, each insert becomes
it's own transaction which is rather expensive. Postgresql 7.2 improves this
a bit but the transaction will help anyway.
HTH,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Canada, Mexico, and Australia form the Axis of Nations That
> Are Actually Quite Nice But Secretly Have Nasty Thoughts About America
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
@ 2002-05-08 07:05 ` Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
0 siblings, 1 reply; 14+ messages in thread
From: Holger Marzen @ 2002-05-08 07:05 UTC (permalink / raw)
To: Martijn van Oosterhout <kleptog@svana.org>; +Cc: Samuel J. Sutjiono <ssutjiono@wc-group.com>; pgsql-general@postgresql.org; pgsql-sql
On Wed, 8 May 2002, Martijn van Oosterhout wrote:
> On Tue, May 07, 2002 at 06:40:32PM -0400, Samuel J. Sutjiono wrote:
>
> > I tried to load data using insert statement to our new database server
> > (Compaq DL580, DL590, DL380 using SCSI driver) but it was very very slow.
> > The database runs on Red Hat Linux 7.2 and PostgreSQL version 7.1.3
> >
> > Does anybody know any idea to what cause this problem ? or things that I
> > need to look or check (in the config. file)
>
> Put them in a trasaction (begin/commit). Without that, each insert becomes
> it's own transaction which is rather expensive. Postgresql 7.2 improves this
> a bit but the transaction will help anyway.
ACK. On a given hardware I get about 150 inserts per second. Using a
begin/end transaction for a group of 100 inserts speeds it up to about
450 inserts per second.
But beware: if one insert fails (duplicate key, faulty data) then you
have to re-insert the remaining rows as single transactions, else all
rows of the previous transaction are discarded.
--
PGP/GPG Key-ID:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xB5A1AFE1
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
@ 2002-05-08 15:02 ` Doug McNaught <doug@wireboard.com>
2002-05-08 17:53 ` Re: Performance issues with compaq server Steve Atkins <steve@blighty.com>
2002-05-08 20:01 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
0 siblings, 2 replies; 14+ messages in thread
From: Doug McNaught @ 2002-05-08 15:02 UTC (permalink / raw)
To: holger@marzen.de; +Cc: Martijn van Oosterhout <kleptog@svana.org>; Samuel J. Sutjiono <ssutjiono@wc-group.com>; pgsql-general@postgresql.org; pgsql-sql
Holger Marzen <holger@marzen.de> writes:
> ACK. On a given hardware I get about 150 inserts per second. Using a
> begin/end transaction for a group of 100 inserts speeds it up to about
> 450 inserts per second.
COPY is even faster as there is less query parsing to be done, plus
you get a transaction per COPY statement even without BEGIN/END.
> But beware: if one insert fails (duplicate key, faulty data) then you
> have to re-insert the remaining rows as single transactions, else all
> rows of the previous transaction are discarded.
Hmm don't you have to ROLLBACK and redo the whole transaction without
the offending row(s), since you can't commit while in ABORT state? Or
am I misunderstanding?
-Doug
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
@ 2002-05-08 17:53 ` Steve Atkins <steve@blighty.com>
1 sibling, 0 replies; 14+ messages in thread
From: Steve Atkins @ 2002-05-08 17:53 UTC (permalink / raw)
To: pgsql-general@postgresql.org
On Wed, May 08, 2002 at 11:02:35AM -0400, Doug McNaught wrote:
> Holger Marzen <holger@marzen.de> writes:
>
> > ACK. On a given hardware I get about 150 inserts per second. Using a
> > begin/end transaction for a group of 100 inserts speeds it up to about
> > 450 inserts per second.
>
> COPY is even faster as there is less query parsing to be done, plus
> you get a transaction per COPY statement even without BEGIN/END.
Does anyone have any performance figures to hand on COPY vs BEGIN/INSERT/END,
on indexed or unindexed tables?
Cheers,
Steve
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
@ 2002-05-08 20:01 ` Holger Marzen <holger@marzen.de>
2002-05-09 04:24 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-09 07:11 ` Re: Performance issues with compaq server Curt Sampson <cjs@cynic.net>
1 sibling, 2 replies; 14+ messages in thread
From: Holger Marzen @ 2002-05-08 20:01 UTC (permalink / raw)
To: Doug McNaught <doug@wireboard.com>; +Cc: Martijn van Oosterhout <kleptog@svana.org>; Samuel J. Sutjiono <ssutjiono@wc-group.com>; pgsql-general@postgresql.org; pgsql-sql
On 8 May 2002, Doug McNaught wrote:
> Holger Marzen <holger@marzen.de> writes:
>
> > ACK. On a given hardware I get about 150 inserts per second. Using a
> > begin/end transaction for a group of 100 inserts speeds it up to about
> > 450 inserts per second.
>
> COPY is even faster as there is less query parsing to be done, plus
> you get a transaction per COPY statement even without BEGIN/END.
Yes, but I wanted to change something in some rows, so I used perl and
insert.
> > But beware: if one insert fails (duplicate key, faulty data) then you
> > have to re-insert the remaining rows as single transactions, else all
> > rows of the previous transaction are discarded.
>
> Hmm don't you have to ROLLBACK and redo the whole transaction without
> the offending row(s), since you can't commit while in ABORT state? Or
> am I misunderstanding?
Postgres complains and doesn't accept the following inserts after a
failed one until end of transaction. I didn't have the time yet to
figure out if it rolls back the preceeding inserts.
Is there a rule in SQL standards that describes what should happen if
some statemens in a transaction fail and the program issues a commit?
--
PGP/GPG Key-ID:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xB5A1AFE1
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-08 20:01 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
@ 2002-05-09 04:24 ` Doug McNaught <doug@wireboard.com>
2002-05-09 11:23 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
1 sibling, 1 reply; 14+ messages in thread
From: Doug McNaught @ 2002-05-09 04:24 UTC (permalink / raw)
To: holger@marzen.de; +Cc: Martijn van Oosterhout <kleptog@svana.org>; Samuel J. Sutjiono <ssutjiono@wc-group.com>; pgsql-general@postgresql.org
Holger Marzen <holger@marzen.de> writes:
> On 8 May 2002, Doug McNaught wrote:
>
> > Hmm don't you have to ROLLBACK and redo the whole transaction without
> > the offending row(s), since you can't commit while in ABORT state? Or
> > am I misunderstanding?
>
> Postgres complains and doesn't accept the following inserts after a
> failed one until end of transaction. I didn't have the time yet to
> figure out if it rolls back the preceeding inserts.
I'm pretty sure that the transaction goes into ABORT state and all you
can do is rollback and start over, minus the offending row(s).
> Is there a rule in SQL standards that describes what should happen if
> some statemens in a transaction fail and the program issues a commit?
I think PG's is standard behavior; that's kind of the whole point of
having transactions.
-Doug
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-08 20:01 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-09 04:24 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
@ 2002-05-09 11:23 ` Holger Marzen <holger@marzen.de>
2002-05-09 11:43 ` Re: Performance issues with compaq server John Gray <jgray@azuli.co.uk>
0 siblings, 1 reply; 14+ messages in thread
From: Holger Marzen @ 2002-05-09 11:23 UTC (permalink / raw)
To: Doug McNaught <doug@wireboard.com>; +Cc: Martijn van Oosterhout <kleptog@svana.org>; Samuel J. Sutjiono <ssutjiono@wc-group.com>; pgsql-general@postgresql.org
On 9 May 2002, Doug McNaught wrote:
> Holger Marzen <holger@marzen.de> writes:
>
> > Is there a rule in SQL standards that describes what should happen if
> > some statemens in a transaction fail and the program issues a commit?
>
> I think PG's is standard behavior; that's kind of the whole point of
> having transactions.
- rolling back the whole transaction if you do a COMMIT
or
- keeping the changes until the first failing statement and ignoring
everything that follows if you do a COMMIT
?
--
PGP/GPG Key-ID:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xB5A1AFE1
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-08 20:01 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-09 04:24 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-09 11:23 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
@ 2002-05-09 11:43 ` John Gray <jgray@azuli.co.uk>
0 siblings, 0 replies; 14+ messages in thread
From: John Gray @ 2002-05-09 11:43 UTC (permalink / raw)
To: holger@marzen.de; +Cc: Doug McNaught <doug@wireboard.com>; Martijn van Oosterhout <kleptog@svana.org>; Samuel J. Sutjiono <ssutjiono@wc-group.com>; pgsql-general@postgresql.org
On Thu, 2002-05-09 at 12:23, Holger Marzen wrote:
> On 9 May 2002, Doug McNaught wrote:
>
> > Holger Marzen <holger@marzen.de> writes:
> >
> > > Is there a rule in SQL standards that describes what should happen if
> > > some statemens in a transaction fail and the program issues a commit?
> >
> > I think PG's is standard behavior; that's kind of the whole point of
> > having transactions.
>
> - rolling back the whole transaction if you do a COMMIT
> or
> - keeping the changes until the first failing statement and ignoring
> everything that follows if you do a COMMIT
>
I can't speak to the phrasing of the standard, but PG behaviour is:
Everything in the transaction is ignored. All the inserts made before
the error, since the BEGIN, are rolled back. All subsequent inserts are
ignored (generating an error that transaction is in ABORT state). The
subsequent COMMIT will end the transaction (and thus clear the abort
state) but *will not commit anything*.
This means that scripts will work as intended -namely that all or none
of the commands within a transaction block will succeed[*]. So if you
split your insert into blocks, and one block fails, you will only need
to correct that block and try to load it again.
Regards
John
[*] This is handy for doing things like reindexing or drop/recreate
table in a script. The drop table stands a good chance of succeeding,
whereas the prospect of a syntax error in the create table makes it more
likely to fail. A subsequent commit of the DROP TABLE would not produce
the end result you intended....
--
John Gray
Azuli IT
www.azuli.co.uk
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-08 20:01 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
@ 2002-05-09 07:11 ` Curt Sampson <cjs@cynic.net>
2002-05-09 11:24 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
1 sibling, 1 reply; 14+ messages in thread
From: Curt Sampson @ 2002-05-09 07:11 UTC (permalink / raw)
To: Holger Marzen <holger@marzen.de>; +Cc: pgsql-sql
On Wed, 8 May 2002, Holger Marzen wrote:
> > COPY is even faster as there is less query parsing to be done, plus
> > you get a transaction per COPY statement even without BEGIN/END.
>
> Yes, but I wanted to change something in some rows, so I used perl and
> insert.
Why not use Perl and COPY?
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-08 01:25 ` Re: Performance issues with compaq server Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Re: Performance issues with compaq server Doug McNaught <doug@wireboard.com>
2002-05-08 20:01 ` Re: Performance issues with compaq server Holger Marzen <holger@marzen.de>
2002-05-09 07:11 ` Re: Performance issues with compaq server Curt Sampson <cjs@cynic.net>
@ 2002-05-09 11:24 ` Holger Marzen <holger@marzen.de>
0 siblings, 0 replies; 14+ messages in thread
From: Holger Marzen @ 2002-05-09 11:24 UTC (permalink / raw)
To: Curt Sampson <cjs@cynic.net>; +Cc: pgsql-sql
On Thu, 9 May 2002, Curt Sampson wrote:
> On Wed, 8 May 2002, Holger Marzen wrote:
>
> > > COPY is even faster as there is less query parsing to be done, plus
> > > you get a transaction per COPY statement even without BEGIN/END.
> >
> > Yes, but I wanted to change something in some rows, so I used perl and
> > insert.
>
> Why not use Perl and COPY?
A good idea. I'll try it if the customer complains about the speed.
--
PGP/GPG Key-ID:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xB5A1AFE1
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
@ 2002-05-09 12:29 ` Denis Gasparin <denis@edistar.com>
2002-05-10 07:49 ` Re: Performance issues with compaq server Curt Sampson <cjs@cynic.net>
2 siblings, 1 reply; 14+ messages in thread
From: Denis Gasparin @ 2002-05-09 12:29 UTC (permalink / raw)
To: Samuel J. Sutjiono <ssutjiono@wc-group.com>; +Cc: Postgresql General Mailing List <pgsql-general@postgresql.org>; pgsql-sql
The Compaq servers you indicated use the smart array controller which is
very very slow in storing data into hard disks. Are you using the RAID?
I suggest you to buy a controller with a larger write cache (the smart
array controller does not have w-cache)... You should note a large
performance progress...
Also do not forget to set fsync to false and to use the COPY command
whenever is possible...
Bye!
--
Doct. Eng. Denis Gasparin: denis@edistar.com
---------------------------
Programmer & System Administrator - Edistar srl
Il mer, 2002-05-08 alle 00:40, Samuel J. Sutjiono ha scritto:
> I tried to load data using insert statement to our new database server (Compaq DL580, DL590, DL380 using SCSI driver) but it was very very slow. The database runs on Red Hat Linux 7.2 and PostgreSQL version 7.1.3
>
> Does anybody know any idea to what cause this problem ? or things that I need to look or check (in the config. file)
>
> I appreciate any help.
>
> Regards,
> Samuel
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Performance issues with compaq server
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-09 12:29 ` Re: Performance issues with compaq server Denis Gasparin <denis@edistar.com>
@ 2002-05-10 07:49 ` Curt Sampson <cjs@cynic.net>
0 siblings, 0 replies; 14+ messages in thread
From: Curt Sampson @ 2002-05-10 07:49 UTC (permalink / raw)
To: Denis Gasparin <denis@edistar.com>; +Cc: Samuel J. Sutjiono <ssutjiono@wc-group.com>; Postgresql General Mailing List <pgsql-general@postgresql.org>
On 9 May 2002, Denis Gasparin wrote:
> The Compaq servers you indicated use the smart array controller which is
> very very slow in storing data into hard disks. Are you using the RAID?
>
> I suggest you to buy a controller with a larger write cache (the smart
> array controller does not have w-cache)... You should note a large
> performance progress...
And take your transaction log off of RAID entirely and put it on
a mirrored pair of disks instead.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2002-05-10 07:49 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2002-05-07 22:40 Performance issues with compaq server Samuel J. Sutjiono <ssutjiono@wc-group.com>
2002-05-07 23:21 ` postgres@vrane.com
2002-05-08 01:25 ` Martijn van Oosterhout <kleptog@svana.org>
2002-05-08 07:05 ` Holger Marzen <holger@marzen.de>
2002-05-08 15:02 ` Doug McNaught <doug@wireboard.com>
2002-05-08 17:53 ` Steve Atkins <steve@blighty.com>
2002-05-08 20:01 ` Holger Marzen <holger@marzen.de>
2002-05-09 04:24 ` Doug McNaught <doug@wireboard.com>
2002-05-09 11:23 ` Holger Marzen <holger@marzen.de>
2002-05-09 11:43 ` John Gray <jgray@azuli.co.uk>
2002-05-09 07:11 ` Curt Sampson <cjs@cynic.net>
2002-05-09 11:24 ` Holger Marzen <holger@marzen.de>
2002-05-09 12:29 ` Denis Gasparin <denis@edistar.com>
2002-05-10 07:49 ` Curt Sampson <cjs@cynic.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox