The NOAA National Data Buoy Center is a government customer
(there are many commercial customers) for our wXstation(R)
product, which uses PostgreSQL as its database.
The number of government customers may increase dramatically
in the near future.
--
P. J. Josh Rovero
It runs fine, and is quite peppy an Fedora Core 2 for AMD 64.
I have not run into any problems.
NTPT wrote:
Will I have some advantages, better performance etc using postgres 7.4
or postgres 8.x on Athlon64 system with 64 bit Linux distro ?Are there
asome benchmark available or someone personal
There are many reports of kernel problems with memory allocation
(too agressive) and swap issues with RHEL 3.0 on both RAID
and non-RAID systems. I hope folks have worked through all
those issues before blaming postgresql.
Tom Lane wrote:
If I thought that a 200% error in memory usage were cause
temporary tables work. Save the complicated
subselect in temporary table, following
queries just simple select on temp table.
Holger Marzen wrote:
Hi all,
if I have something like this:
SELECT column1,
(... complicated subselect ...),
column1 - (... same subselect as above ...)
Thanks to all who suggested indexing; I added an index to
the running database, and delete performance immediately
increased by a factor or 10.
The problem now is that when I vacuum verbose analyze, the
pg_largeobject system table takes *forever* (tens of minutes).
A new postmaster seems to be
Looking for some hints on how to speed up deletes Thanks in advance
Using PostgreSQL 7.1.2 on hppa2.0-hp-hpux10.20, compiled by GCC 2.95.3
(2 processors)
Have a file record wx_grib_file, with data stored as large object.
The rule wx_grib_file_delete does the lo_unlink on grib_file_id.
