From: | Curt Sampson <cjs(at)cynic(dot)net> |
---|---|
To: | Jason Earl <jason(dot)earl(at)simplot(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Indexes on Aggregate Functions |
Date: | 2002-07-01 06:18:09 |
Message-ID: | Pine.NEB.4.43.0207011513000.408-100000@angelic.cynic.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 28 Jun 2002, Jason Earl wrote:
> SELECT setval('test_s_seq', (SELECT max(s) + 1 FROM test));
>
> PostgreSQL doesn't use the indexes on aggregate functions (like max())
> so it would be faster on large tables to write that as:
>
> SELECT setval('test_s_seq', (SELECT s + 1 FROM test ORDER BY s DESC
> LIMIT 1));
I've wondered about this, actually. Why doesn't postgres use the
indexes? For something like MAX(s) it would certainly be a lot faster.
Another cool optimisation that MS SQL Server does is, if the
information requested is looked up in an index, and all the columns
you're retrieving are already in the index data, it doesn't bother
retrieving the values from the table itself (though presumably it
checks for triggers to execute and so on). E.g., if you have
CREATE TABLE foo (
mykey int PRIMARY KEY,
otherkey_part1 int NOT NULL,
otherkey_part2 varchar(255) NOT NULL,
morestuff varchar(255) NOT NULL);
CREATE INDEX otherkeys ON foo (otherkey_part1, otherkey_part2);
SELECT otherkey_part1, otherkey_part2 FROM foo
WHERE otherkey_part1 = 17;
that query will read only the index, not the table itself.
cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-07-01 07:01:50 | Re: Indexes on Aggregate Functions |
Previous Message | Alvaro Herrera | 2002-07-01 03:13:19 | Re: literature about search-algorithms |