From: | Grant Johnson <grant(at)amadensor(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Slow count(*) again... |
Date: | 2011-02-04 01:18:28 |
Message-ID: | 4D4B53E4.6010701@amadensor.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On PostgreSQL, the difference in no hints and hints for that one query
with skewed data is that the query finishes a little faster. On some
others, which shall remain nameless, it is the difference between
finishing in seconds or days, or maybe never. Hints can be useful, but
I can also see why they are not a top priority. They are rarely needed,
and only when working around a bug. If you want them so badly, you have
the source, write a contrib module (can you do that on Oracle or
MSSQL?) If I have a choice between the developers spending time on
implementing hints, and spending time on improving the optimiser, I'll
take the optimiser.
Tom Kyte agrees:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:8912905298920
http://tkyte.blogspot.com/2006/08/words-of-wisdom.html
Oracle can be faster on count queries, but that is the only case I have
seen. Generally on most other queries, especially when it involves
complex joins, or indexes on text fields, PostgreSQL is faster on the
same hardware.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2011-02-04 01:28:08 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Jeremy Harris | 2011-02-04 00:49:52 | Re: [HACKERS] Slow count(*) again... |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2011-02-04 01:28:08 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Jeremy Harris | 2011-02-04 00:49:52 | Re: [HACKERS] Slow count(*) again... |