From: | Doug Fields <dfields-pg-general(at)pexicom(dot)com> |
---|---|
To: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Cc: | "Doug Fields" <dfields-pg-general(at)pexicom(dot)com>, petedaly(at)ix(dot)netcom(dot)com, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Non-linear Performance |
Date: | 2002-06-09 00:36:50 |
Message-ID: | 5.1.0.14.2.20020608203057.01f03068@pop.pexicom.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>I can see the benefit when you're executing a small number of
>enormously expensive queries (and those queries are CPU-bound);
>but that situation is quite rare, IME.
Bingo. I have some self-joins (Order N^2 at worst) on VARCHAR fields,
which, if you have tables with millions of rows, take full CPU of 900
seconds or more sometimes - and I have a need to expand from 7-digit to
9-digit row counts - which could mean 10,000 times slower. I can speed that
up from P3-1ghz to P4-2.4ghz, but not much.
The best way to solve the above problem is to figure out a more efficient
query, of course, or avoid the need for the query in the first place.
Sometimes easier said than done.
Also, the relatively slow speed for inserts with VARCHAR indices would
conceivably be helped; I often insert data into a temp table and then
INSERT INTO SELECT *... from the temp to the other one to get reasonable
performance. I'd love to be able to turn off MVCC for those kinds of
things; that is, instead of seeing one universal insert of 3 million rows,
I wouldn't mind seeing them dribble in one at a time, thereby saving the
overhead of MVCCing them.
Cheers,
Doug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-09 01:43:11 | Re: sorting/grouping/(non-)unique indexes bug |
Previous Message | Neil Conway | 2002-06-08 22:35:44 | Re: Non-linear Performance |