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

Re: query planner weirdness?

From: "Bob Duffey" <bobduffey68(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: query planner weirdness?
Date: 2008-06-28 04:48:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
2008/6/28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> "Bob Duffey" <bobduffey68(at)gmail(dot)com> writes:
> > I'm seeing some query plans that I'm not expecting.  The table in
> question
> > is reasonably big (130,000,000 rows).  The table has a primary key,
> indexed
> > by one field ("ID", of type bigint).  Thus, I would expect the following
> > query to simply scan through the table using the primary key:
> > select * from "T" order by "ID"
> This is not wrong, or at least not obviously wrong.  A full-table
> indexscan is often slower than seqscan-and-sort.  If the particular
> case is wrong for you, you need to look at adjusting the planner's
> cost parameters to match your environment.  But you didn't provide any
> evidence that the chosen plan is actually worse than the alternative ...

Hi Tom,

Thanks for the reply.  Is there some way I can provide evidence of the
alternative being slower/faster?  I guess that's my intuition, but since I
can't figure out how to get postgres to use the alternative as the query
plan, I can't test if it's slower!


In response to

pgsql-general by date

Next:From: Adam RichDate: 2008-06-28 04:53:00
Subject: Re: query planner weirdness?
Previous:From: hubert depesz lubaczewskiDate: 2008-06-28 04:41:25
Subject: Re: freebsd + postgresql 8.3.3 = 100% of cpu usage onstats collector?

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