tuning large selects

From: Werner Reisberger <wreis(at)datacomm(dot)ch>
To: pgsql-sql(at)hub(dot)org
Subject: tuning large selects
Date: 1999-10-29 19:36:03
Message-ID: 19991029213603.B830@tribe.free.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

I am running a db (v. 6.4.2) accessible via DBI/Pg from the internet.
Recently I observed several running postmaster processes consuming lots of CPU,
resulting in a high load of the machine. There was nobody connected to
the db from the net. Later I saw that my db partition was filled to 100 %
by a huge file (pg_psort.189xx). My db partition is approx. 950 MB. The
db consumes 15 MB and the file consumed the rest.

I guess the pg_psort file grew to this dimension because the select
possibilities I am offering via the CGI are not well designed. Maybe
someone could give me some advice how to make it more efficient.

The select in question accesses only one table (notcat) with approx.
6000 rows and 15 columns. The CGI allows to choose how many columns will
be returned as a result and what columns are used to constrain the search.
There are 8 columns which can be used to constrain the search. The values
of each such column are Or-ed together in the where clause. The columns
itself are AND-ed.

Example:

select * from notcat where (col1 ~* 'val1' OR col1 ~* 'val2' ....) AND
(col2 ~* 'val1' OR col2 ~* 'val2' ....) AND (col3 ~* 'val1' ...

To make things worse there could be several dozens values in each column
used in the where clause.

--Werner

Browse pgsql-sql by date

  From Date Subject
Next Message Moray McConnachie 1999-10-29 20:02:00 Re: [SQL] trivial problem
Previous Message tjk@tksoft.com 1999-10-29 18:12:49 Re: [SQL] trivial problem