This is not a bug -- please don't post feature requests to pgsql-bugs.
pgsql-general would be better.
On Tue, Feb 21, 2017 at 11:58 AM, <james@emerton.info> wrote:
> postgres=# EXPLAIN SELECT * FROM test ORDER BY key, id;
> QUERY PLAN
> ---------------------------------------------------------------
> Sort (cost=66.83..69.33 rows=1000 width=20)
> Sort Key: key, id
> -> Seq Scan on test (cost=0.00..17.00 rows=1000 width=20)
> (3 rows)
>
> postgres=# EXPLAIN SELECT * FROM test ORDER BY key;
> QUERY PLAN
> ------------------------------------------------------------------------------
> Index Scan using test_key_key on test (cost=0.28..49.27 rows=1000
> width=20)
> (1 row)
>
>
> It seems that these two queries are effectively identical, but the query
> planner makes significantly different choices. In our application there are
> several additional tables joined and the multiple column sort version is
> over two orders of magnitude slower.
What happens when the "key" column here has NULL values?
--
Peter Geoghegan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
