Re: cutting down the TODO list thread
От | John Naylor |
---|---|
Тема | Re: cutting down the TODO list thread |
Дата | |
Msg-id | CAFBsxsE6Wg_HFtAfk0C8FpiWEtypu6zZ7bscO2H9e-RQY+_u8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: cutting down the TODO list thread (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: cutting down the TODO list thread
|
Список | pgsql-hackers |
Hi,
I let this drop off my radar a few months ago, but I'm going to try to get back into the habit of looking at a few items a week. As before, let me know in the next few days if anyone has thoughts or objections.
(Optimizer / Executor)
- Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com
This seems to have been rejected.
- Improve use of expression indexes for ORDER BY
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php
Skimming the thread, I'm not quite sure if index-only scans (not available at the time) solves the problem, or is orthogonal to it?
- Modify the planner to better estimate caching effects
http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
Huge discussion. This sounds like a research project, and maybe a risky one.
- Allow shared buffer cache contents to affect index cost computations
http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
Related to the above, but has a more specific approach in mind. The discussion thread is not useful for getting one's head around how to think about the problem, much less to decide if it's worth working on -- it's mostly complaining about the review process. Independent of that, the idea of inspecting the buffer cache seems impractical.
--
John Naylor
EDB: http://www.enterprisedb.com
I let this drop off my radar a few months ago, but I'm going to try to get back into the habit of looking at a few items a week. As before, let me know in the next few days if anyone has thoughts or objections.
(Optimizer / Executor)
- Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold
http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com
This seems to have been rejected.
- Improve use of expression indexes for ORDER BY
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php
Skimming the thread, I'm not quite sure if index-only scans (not available at the time) solves the problem, or is orthogonal to it?
- Modify the planner to better estimate caching effects
http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php
Huge discussion. This sounds like a research project, and maybe a risky one.
- Allow shared buffer cache contents to affect index cost computations
http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php
Related to the above, but has a more specific approach in mind. The discussion thread is not useful for getting one's head around how to think about the problem, much less to decide if it's worth working on -- it's mostly complaining about the review process. Independent of that, the idea of inspecting the buffer cache seems impractical.
--
John Naylor
EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: