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

Re: [HACKERS] alter_table.sql

From: Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] alter_table.sql
Date: 2000-03-07 16:40:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
OK - got it! It is because vacuum analyze <tablename> doesn't work for me,
therefore the select doesn't use indices, so uses a sequential rather than
index scan => my rows are returned out of order.

Thanks for the pointer.



On Tue, Mar 07, 2000 at 11:19:08AM -0500, Tom Lane wrote:
> Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> writes:
> > In the alter table regression test, alter_table.sql, it says:
> > -- 20 values, sorted
> > SELECT unique1 FROM ten_k WHERE unique1 < 20;
> > Why sorted? Shouldn't it be
> > SELECT unique1 FROM ten_k WHERE unique1 < 20 ORDER BY unique1;
> > if we really expect the output to be sorted?
> The regression test author evidently expected the optimizer to choose an
> indexscan, which will produce the values in sorted order as a byproduct.
> I agree this code is bogus in a theoretical sense, but I don't think
> it's worth worrying about until we alter the optimizer so far that it
> doesn't choose an indexscan for this query.  (Indeed, that might be a
> sign of an optimizer bug --- so I'd look into why the behavior changed
> before changing the regress test.)
> Since our regress tests are checked on the basis of exact equality of
> output, in theory every single regress test SELECT that doesn't specify
> "ORDER BY" is broken, because in theory the system could choose to put
> out the tuples in some other order than what's in the regress test
> reference outputs.  But in practice, the implementation-dependent
> ordering you get is reproducible across platforms, so the tests
> accomplish what they're supposed to.  Every so often we have to throw in
> an ORDER BY when we find that one of the test cases isn't so
> reproducible.
> 			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-03-07 16:47:15
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Previous:From: Tom LaneDate: 2000-03-07 16:34:04
Subject: Re: [HACKERS] library policy question

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