MIME-Version: 1.0
References: 
 <CAFBsxsEd_-WJ78_Sv=iP+T3-bM5+b6ORONBQTZVb0RDETvmqDQ@mail.gmail.com>
 <20201110230848.GB12947@momjian.us>
 <CAFBsxsGP+qiLnC2KkOEW2URvvwC0zeYjYcEBsbZoBkiL5JSCKg@mail.gmail.com>
 <CAFBsxsFTD45K5S3oJQbDSvA-nuB6DiykCGMk7OfU7VijT9bJMw@mail.gmail.com>
 <CAFBsxsF-uA=SvFNJGNin68KRfrCautEwEN0JL4EimGaUM0zcsg@mail.gmail.com>
 <996474.1605726312@sss.pgh.pa.us>
 <CAFBsxsEJs036Bc-gEho0Dw00Smbo3PnOdQf-ZOB5f5EUWEEUuQ@mail.gmail.com>
 <CAFBsxsGQCwrdMu2ThR8xTvu4pG9kv7mbt542OhZ=YKnxqW92cw@mail.gmail.com>
 <20201123153936.GA29448@momjian.us>
 <CAFBsxsGekd50U0SpxUfUaG7mWz1_q+pkNcFHv1Ct40PkBVY+Dg@mail.gmail.com>
 <20201217145858.GA23260@momjian.us>
In-Reply-To: <20201217145858.GA23260@momjian.us>
From: John Naylor <john.naylor@enterprisedb.com>
Date: Wed, 19 May 2021 13:52:03 -0400
Message-ID: 
 <CAFBsxsE6Wg_HFtAfk0C8FpiWEtypu6zZ7bscO2H9e-RQY+_u8g@mail.gmail.com>
Subject: Re: cutting down the TODO list thread
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000680f7205c2b27db7"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFBsxsE6Wg_HFtAfk0C8FpiWEtypu6zZ7bscO2H9e-RQY%2B_u8g%40mail.gmail.com>
Precedence: bulk

--000000000000680f7205c2b27db7
Content-Type: text/plain; charset="UTF-8"

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

--000000000000680f7205c2b27db7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>I let this drop off my radar a few months ago, =
but I&#39;m going to try to get back into the habit of looking at a few ite=
ms a week. As before, let me know in the next few days if anyone has though=
ts or objections.<br><br>(Optimizer / Executor)<br><br>- Consider increasin=
g the default values of from_collapse_limit, join_collapse_limit, and/or ge=
qo_threshold<br><br><a href=3D"http://archives.postgresql.org/message-id/41=
36ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com">http://archives.p=
ostgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.g=
mail.com</a><br><br>This seems to have been rejected.<br><br>- Improve use =
of expression indexes for ORDER BY<br><br><a href=3D"http://archives.postgr=
esql.org/pgsql-hackers/2009-08/msg01553.php">http://archives.postgresql.org=
/pgsql-hackers/2009-08/msg01553.php</a><br><br>Skimming the thread, I&#39;m=
 not quite sure if index-only scans (not available at the time) solves the =
problem, or is orthogonal to it?<br><br>- Modify the planner to better esti=
mate caching effects<br><br><a href=3D"http://archives.postgresql.org/pgsql=
-performance/2010-11/msg00117.php">http://archives.postgresql.org/pgsql-per=
formance/2010-11/msg00117.php</a><br><br>Huge discussion. This sounds like =
a research project, and maybe a risky one.<br><br>- Allow shared buffer cac=
he contents to affect index cost computations<br><br><a href=3D"http://arch=
ives.postgresql.org/pgsql-hackers/2011-06/msg01140.php">http://archives.pos=
tgresql.org/pgsql-hackers/2011-06/msg01140.php</a><br><br>Related to the ab=
ove, but has a more specific approach in mind. The discussion thread is not=
 useful for getting one&#39;s head around how to think about the problem, m=
uch less to decide if it&#39;s worth working on -- it&#39;s mostly complain=
ing about the review process. Independent of that, the idea of inspecting t=
he buffer cache seems impractical.<br><br>--<br>John Naylor<br>EDB: <a href=
=3D"http://www.enterprisedb.com">http://www.enterprisedb.com</a></div>

--000000000000680f7205c2b27db7--