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

Re: Query only slow on first run

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
Cc: cluster <skrald(at)amossen(dot)dk>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Query only slow on first run
Date: 2007-11-28 00:25:54
Message-ID: 15029.1196209554@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Steinar H. Gunderson" <sgunderson(at)bigfoot(dot)com> writes:
> You could make an index on (question_id,status) (or a partial index on
> question id, with status=1 as the filter), but I'm not sure how much it would
> help you unless the questions table is extremely big. It doesn't appear to
> be; in fact, it appears to be all in RAM, so that's not your bottleneck.

Wouldn't help, because the accesses to "questions" are not the problem.
The query's spending nearly all its time in the scan of "posts", and
I'm wondering why --- doesn't seem like it should take 6400msec to fetch
646 rows, unless perhaps the data is just horribly misordered relative
to the index.  Which may in fact be the case ... what exactly is that
"random_number" column, and why are you desirous of ordering by it?
For that matter, if it is what it sounds like, why is it sane to group
by it?  You'll probably always get groups of one row ...

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2007-11-28 00:28:18
Subject: Re: Query only slow on first run
Previous:From: Dave DutcherDate: 2007-11-27 23:47:31
Subject: Re: Query only slow on first run

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