Skip site navigation (1) Skip section navigation (2)

Query Analysis

From: <typea(at)l-i-e(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Query Analysis
Date: 2002-11-20 23:40:46
Message-ID: 51042.216.80.95.13.1037835646.squirrel@www.l-i-e.com (view raw or flat)
Thread:
Lists: pgsql-performance
Direct Cc: would be MUCH appreciated!

I'm using PostgreSQL 7.1.3

My FIRST question is:

How come I can't seem to get any of that nifty profiling output to
/var/log/messages?

[aside]
Not in /var/log/pgsql nor in /var/lib/pgsql/data/pg.log either.  Don't
care where it goes, so long as I can find it...  While I realize that this
is very configurable, some "clues" to newbies about the usual places would
have been most welcome in the docs.
[/aside]


I have:
  Altered postgresql.conf to turn "on" the show_query_stats (et al) as
well as syslog = 2
  Altered /etc/rc.d/init/postgresql to be:
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl  -D $PGDATA -o '-i -s ' -p
/usr/bin/postmaster start  > /dev/null 2>&1" < /dev/null
  Altered /var/lib/pgsql/postmaster.opts to be:
/usr/bin/postmaster '-D' '/var/lib/pgsql/data' '-i' '-s'

Once I'm in psql, I use SET to turn them on as well.

This resulted in all my ERROR and NOTICE messages going into
/var/log/messages, but *NOT* any sort of nifty query analysis type stuff.

So what did I miss?  Is there another client/server spot where I need to
get that '-s' in there?

Is there another switch to actually kick-start it?  The docs are probably
real clear to y'all, but I'm obviously missing something simple here...


Of course, the root problem is a monster query that suddenly takes far far
too long...

I realize that I'm trying to do a full-text search, *BUT* a similar query
"works fine"...

Why does this take minutes:

SELECT DISTINCT *, 0 + (0 + 10 * (lower(title) like '%einstein%') ::int +
10 * (lower(author_flattened) like '%einstein%') ::int + 30 *
(lower(subject_flattened) like '%einstein%') ::int + 30 * (lower(text)
LIKE '%einstein%') ::int + 9 * (substring(lower(title), 1, 20) like
'%einstein%') ::int + 25 * (substring(lower(text), 1, 20) LIKE
'%einstein%') ::int ) AS points FROM article WHERE TRUE AND (FALSE OR
(lower(title) like '%einstein%') OR (lower(author_flattened) like
'%einstein%') OR (lower(subject_flattened) like '%einstein%') OR
(lower(text) LIKE '%einstein%') ) ORDER BY points desc, volume, number,
article.article LIMIT 10, 0

while this takes seconds:

SELECT *, 0 + 3 * ( title like '%Einstein%' )::int + 3 * ( author like
'%Einstein%' )::int + ( ( 1 + 1 * ( lower(text) like '%einstein%' )::int )
+ ( 0 + ( subject like '%Einstein%' )::int ) ) AS points FROM article
WHERE TRUE AND title like '%Einstein%' AND author like '%Einstein%' AND (
( TRUE AND lower(text) like '%einstein%' ) OR ( FALSE OR subject like
'%Einstein%' ) ) ORDER BY points desc, volume, number, article.article
LIMIT 10, 0


Is it the function calls to lower() which I have yet to implement on the
second query?

Is it the sheer number of rows being returned?

Do a lot of "OR" sub-parts to the WHERE drag it down?

Article has ~17000 records in it.
The 'text' field is the actual contents of a magazine article.

I would ask if it was the ~* (REGEXP) but that hasn't even kicked in for
this single-term ('Einstein') input! :-^

We're talking about minutes instead of seconds here.

All fields are of type 'text'

VACUUM VERBOSE ANALYZE is running nightly

/proc/cpuinfo sez:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Pentium(R) III CPU family      1400MHz
stepping        : 1
cpu MHz         : 1406.005
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips        : 2804.94

Finally, any "rules of thumb" about that one 512 RAM size thingie in
postmaster.conf would be especially appreciated...

If you're willing to actually poke at the search engine with other inputs,
I'd be happy to provide a URL off-list.




Responses

pgsql-performance by date

Next:From: Josh BerkusDate: 2002-11-20 23:52:40
Subject: Re: Query Analysis
Previous:From: Hannu KrosingDate: 2002-11-20 20:26:22
Subject: Re: selects from large tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group