From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: cutting down the TODO list thread |
Date: | 2023-05-17 02:54:55 |
Message-ID: | CAFBsxsFq7H1Uh1RAYWsmtNe=FTvD_1SESMVSfjtMijynRkeQMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 16, 2023 at 1:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> Add support for polymorphic arguments and return types to languages
other than PL/PgSQL
> >> Add support for OUT and INOUT parameters to languages other than
PL/PgSQL
> > These actually seem like pretty interesting projects.
>
> Yeah. I'm surprised that nobody has gotten around to scratching
> this itch yet.
Okay, keeping these.
On Tue, May 16, 2023 at 3:50 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:
>
> On 2023-May-13, John Naylor wrote:
> > Consider having single-page pruning update the visibility map
> Hmm, I agree with removing the entry from the TODO list, but why is this
> something we Do Not Want? If somebody shows up and do some analysis
> that in a certain workload it is beneficial to do this, then I don't
> think we should turn them down.
Okay, removing but not adding to Do Not Want.
On Tue, May 16, 2023 at 8:52 PM Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:
>
> On Tue, 16 May 2023 at 14:27, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
> > <boekewurm+postgres(at)gmail(dot)com> wrote:
> > > Agreed; and that's why I'm not against removing the specific wording
> > > of the item. This may not have been clearly described in my previous
> > > mail, but I would instead like to see a TODO list item which covers
> > > the need to improve the number of cases where we provide actionable
> > > advice, and specifically those cases where there is not One Obvious
> > > Issue (OOI;s like when getting close to wraparound; or close
> > > checkpoints, or ...).
> >
> > My vote is for just removing the item, rather than putting it on the
> > not wanted list. I don't think it's useful to put things as general as
> > what you say here on the list. But putting this item in the not wanted
> > section might imply that it's not an area we're looking to improve,
> > which as you say, is false.
>
> That makes sense. Agreed.
(This was for SET PERFORMANCE_TIPS) -- removing but not adding to Do Not
Want.
I've removed all else proposed to simply remove.
Also removing "ECPG - Fix nested C comments" as done.
As for this:
On Sat, May 13, 2023 at 12:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Improve speed of tab completion
> > -> Is this still a problem?
>
> I keep worrying that tab-complete.c will become so ungainly as to
> present a human-scale performance problem. But there's been pretty
> much zero complaints so far. Let's drop this one until some actual
> issue emerges.
Looking in the thread, the issue has to do with catalog queries, and in
fact I must have fat-fingered copying the entry -- it should be "Improve
speed of tab completion by using LIKE":
http://www.postgresql.org/message-id/20120821174847.GL1267@tamriel.snowman.net
I've left it alone for now just in case.
(I have yet to think about concrete revisions that seem needed, but I'll do
that separately.)
--
John Naylor
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-05-17 03:04:42 | Re: Reload configuration more frequently in apply worker. |
Previous Message | Julien Rouhaud | 2023-05-17 02:50:29 | Re: cutting down the TODO list thread |