Re: [HACKERS] Slow count(*) again...
| От | Ross J. Reedstrom |
|---|---|
| Тема | Re: [HACKERS] Slow count(*) again... |
| Дата | |
| Msg-id | 20110203192442.GF31926@rice.edu обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Slow count(*) again... (Chris Browne <cbbrowne@acm.org>) |
| Список | pgsql-performance |
On Thu, Feb 03, 2011 at 12:44:23PM -0500, Chris Browne wrote: > mladen.gogala@vmsinfo.com (Mladen Gogala) writes: > > Hints are not even that complicated to program. The SQL parser should > > compile the list of hints into a table and optimizer should check > > whether any of the applicable access methods exist in the table. If it > > does - use it. If not, ignore it. This looks to me like a > > philosophical issue, not a programming issue. > > It's worth looking back to what has already been elaborated on in the > ToDo. > > http://wiki.postgresql.org/wiki/Todo > ----------------------------------- > Optimizer hints (not wanted) > > Optimizer hints are used to work around problems in the optimizer and > introduce upgrade and maintenance issues. We would rather have the > problems reported and fixed. We have discussed a more sophisticated > system of per-class cost adjustment instead, but a specification remains > to be developed. And as to the 'wait around for a new version to fix that': there are constantly excellent examples of exactly this happening, all the time with PostgreSQL - most recent example I've seen - http://archives.postgresql.org/pgsql-performance/2011-01/msg00337.php The wait often isn't long, at all. Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Systems Engineer & Admin, Research Scientist phone: 713-348-6166 Connexions http://cnx.org fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
В списке pgsql-performance по дате отправления: