Re: Seq Scan - Mailing list pgsql-general

From Tyler Durden
Subject Re: Seq Scan
Date
Msg-id ab07320e0706011017u55ceacd8tb428b89128a53975@mail.gmail.com
Whole thread Raw
In response to Re: Seq Scan  ("John D. Burger" <john@mitre.org>)
Responses Re: Seq Scan
List pgsql-general
Yes,  either case happens the same.
I'm come recently from MySQL and it works in a different way.
I find strange that a simple SELECT COUNT(...) is so slow with only
700 000 records.
Has been a nightmare optimizing this tables/queries.
Sorry about this silly question, but I'm new to Posgresql.

Thanks,
Tyler

On 6/1/07, John D. Burger <john@mitre.org> wrote:
> You mention SELECT COUNT(ID), but your example shows SELECT ID.  In
> either case, the planner is choosing the correct plan.  Indexes exist
> to save the engine from visiting every row in the table, but both of
> these queries require every row to be visited anyway.
>
> Perhaps you think that these queries can be satisfied without
> visiting the actual table rows at all, using only the index.  This is
> incorrect - PG doesn't work that way.
>
> - John Burger
>    MITRE
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

pgsql-general by date:

Previous
From: Mike Ginsburg
Date:
Subject: Interval Rounding
Next
From: "Joshua D. Drake"
Date:
Subject: Looking for Graphical people for PostgreSQL tradeshow signage