Martijn van Oosterhout writes:
> At a guess your table is not big enough to make an index worthwhile. If
> your table is only a few pages long, it's just not efficient to lookup
> an index first.
> If you post the results of EXPLAIN ANALYZE we can tell you for sure.
Actually, it would be interest
On Sat, Dec 09, 2006 at 11:35:39AM +0100, Luca Ferrari wrote:
> And when the cluster is rebuilt? I mean, in theory, a clustered index should
> be sorted at any point in time, that means I've got much cost for
> insert/update cause I need to sort again the index when I'm performing the
> insert/u
On Saturday 09 December 2006 03:48 Tom Lane's cat, walking on the keyboard,
wrote:
> Well, CLUSTER does not guarantee that the data remains sorted --- as
> soon as you do any updates it won't be anymore. So the planner can
> never assume that a plain seqscan delivers correctly sorted output.
And
Luca Ferrari <[EMAIL PROTECTED]> writes:
> excuse me for this trivial question, but here's my doubt:
> create table person(varchar id, varchar surname, varchar name)
> with id primary key. Now, the query:
> select * from person order by surname,name
> provide me an explaination that is sequential s
Luca Ferrari <[EMAIL PROTECTED]> wrote:
>
> Hi all,
> excuse me for this trivial question, but here's my doubt:
> create table person(varchar id, varchar surname, varchar name)
> with id primary key. Now, the query:
> select * from person order by surname,name
> provide me an explaination that is s
Hi all,
excuse me for this trivial question, but here's my doubt:
create table person(varchar id, varchar surname, varchar name)
with id primary key. Now, the query:
select * from person order by surname,name
provide me an explaination that is sequential scan + sort, as I expected.
After that I bu