Re: Non-linear Performance

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

In response to

Responses

Browse pgsql-general by date

  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