Re: cutting down the TODO list thread - Mailing list pgsql-hackers
| From | John Naylor |
|---|---|
| Subject | Re: cutting down the TODO list thread |
| Date | |
| Msg-id | CAFBsxsFq7H1Uh1RAYWsmtNe=FTvD_1SESMVSfjtMijynRkeQMg@mail.gmail.com Whole thread Raw |
| In response to | Re: cutting down the TODO list thread (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
| List | pgsql-hackers |
On Tue, May 16, 2023 at 1:16 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.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@alvh.no-ip.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@gmail.com> wrote:
>
> On Tue, 16 May 2023 at 14:27, Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
> > <boekewurm+postgres@gmail.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@sss.pgh.pa.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.)
>
> Robert Haas <robertmhaas@gmail.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@alvh.no-ip.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@gmail.com> wrote:
>
> On Tue, 16 May 2023 at 14:27, Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
> > <boekewurm+postgres@gmail.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@sss.pgh.pa.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.)
pgsql-hackers by date: