Greg Stark wrote:
William Yu [EMAIL PROTECTED] writes:
Biggest speedup I've found yet is the backup process (PG_DUMP -- GZIP). 100%
faster in 64-bit mode. This drastic speed might be more the result of 64-bit
GZIP though as I've seen benchmarks in the past showing encryption/compression
running 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua Marsh wrote:
| Thanks for all of your help so far. Here is some of the information
| you guys were asking for:
|
| Test System:
| 2x AMD Opteron 244 (1.8Ghz)
| 8GB RAM
| 7x 72GB SCSI HDD (Raid 5)
You probably want to look at investing in a SAN.
Good day,
I use pgsql 7.4: I would like to know if indexes will solve my problem
(I fear the system will become slow with the time). And also some
questions on how pgsql optimise for speed.
*Database*
-- Assuming those tables (not original, but enought to get the point):
CREATE TABLE prod.jobs
Hi,
I have a strange (for me) result ... Why the second request is really quicker
with a Seq Scan than the first one with a DISTINCT and using an index !?
The table have really 183957 rows ... not like the Seq Scan seems to
expect ... !? I understand nothing here ...
Thanks for your
Sorry if I'm contributing more noise to the signal here, just thought
I'd repost this one to the list since it may have gotten lost in all
the garbage from the guy unhappy about the usenet thing..
-- Forwarded message --
From: Allen Landsidel [EMAIL PROTECTED]
Date: Fri, 12 Nov
I'm just currious about which is the best, if I have many query based
on the first one:
-- suppose this view (used many times):
CREATE VIEW prod.alljobs_view AS
SELECT *
FROM prod.jobs
LEFT JOIN prod.jobs_products ON jobs.job_id = jobs_products.job_id;
-- suppose this other query:
CREATE
Alexandre Leclerc [EMAIL PROTECTED] writes:
-- suppose this view (used many times):
CREATE VIEW prod.alljobs_view AS
SELECT *
FROM prod.jobs
LEFT JOIN prod.jobs_products ON jobs.job_id = jobs_products.job_id;
-- suppose this other query:
CREATE VIEW prod.orders_jobs_view AS
Vivek,
I ran into the exact same problem you did. I tried many, many changes to
the conf file, I tried O.S. tuning but performance stunk. I had a fairly
simple job that had a lot of updates and inserts that was taking 4 1/2
hours. I re-wrote it to be more Postgres friendly - meaning less
