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: | 14422aad0806272148y18882ad4wbf6f5f0268c10b1a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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!
Bob
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Rich | 2008-06-28 04:53:00 | Re: query planner weirdness? |
Previous Message | hubert depesz lubaczewski | 2008-06-28 04:41:25 | Re: freebsd + postgresql 8.3.3 = 100% of cpu usage on stats collector? |