From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | "John D(dot) Burger" <john(at)mitre(dot)org> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: The planner chooses seqscan+sort when there is an |
Date: | 2006-05-03 15:57:58 |
Message-ID: | 1146671878.14093.176.camel@coppola.muc.ecircle.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2006-05-03 at 17:48, John D. Burger wrote:
> Csaba Nagy wrote:
>
> > select * from table order by col_1;
> >
> > Isn't it supposed to choose the index scan at least when
> > enable_seqscan=off ? Even if it is indeed not faster to do the index
> > scan than seqscan+sort.
>
> I think because you've asked for every row, it's going to have to scan
> the whole table anyway, to determine MVCC "liveness" of the rows
> (sorry, dunno what the correct word is).
But I also asked for _ordered_ results, which the seq scan is not
covering, but the index does... and I specifically disabled sequential
scan. That means the planner is not even considering the primary key
index, and I would like to know why...
Actually this is a problem for me in a more complex query, which also
needs this table ordered by that column, and it results in the same plan
fragment with sequential scan + sort.
Thanks,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2006-05-03 16:01:10 | Re: The planner chooses seqscan+sort when there is an |
Previous Message | Andreas Kretschmer | 2006-05-03 15:54:33 | Re: The planner chooses seqscan+sort when there is an index on the sort column |