On Tue, May 16, 2023 at 1:16 AM Tom Lane wrote:
>
> Robert Haas 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
On Tue, 16 May 2023, 02:05 Matthias van de Meent,
>
> The result I got when searching for "automatic postgresql index
> suggestions" was a combination of hypopg, pg_qualstats and some manual
> glue to get suggested indexes in the current database - but none of
> these are available in the main
On Tue, 16 May 2023 at 14:27, Robert Haas wrote:
>
> On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
> 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
On Tue, May 16, 2023 at 8:18 AM Matthias van de Meent
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
On Mon, 15 May 2023 at 20:51, Robert Haas wrote:
>
> On Mon, May 15, 2023 at 2:05 PM Matthias van de Meent
> wrote:
> > > Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE,
> > > and CLUSTER
> > > -> There are external tools that help with this kind of analysis
> >
> >
On Tue, May 16, 2023 at 4:50 AM Alvaro Herrera wrote:
> 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
On 2023-May-13, John Naylor wrote:
>
> 2. Propose to move to the "Not Wanted list":
> Consider having single-page pruning update the visibility map
> -> Comment from Heikki in the thread:
> "I think I was worried about the possible performance impact of having to
> clear the
On Mon, May 15, 2023 at 2:05 PM Matthias van de Meent
wrote:
> > Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE,
> > and CLUSTER
> > -> There are external tools that help with this kind of analysis
>
> Althrough there are external tools which help with the analysis, the
Robert Haas writes:
> On Sat, May 13, 2023 at 12:42 AM John Naylor
> wrote:
>> Add support for polymorphic arguments and return types to languages other
>> than PL/PgSQL
>> -> Seems if someone needed this, they would say so (no thread).
>>
>> Add support for OUT and INOUT parameters to
On Sat, 13 May 2023 at 06:42, John Naylor wrote:
>
>
> On Mon, Feb 6, 2023 at 11:04 AM John Naylor
> wrote:
> > I'll try to get back to culling the list items at the end of April.
>
> I've made another pass at this. Previously, I went one or two sections at a
> time, but this time I tried just
On Sat, May 13, 2023 at 12:42 AM John Naylor
wrote:
> Add support for polymorphic arguments and return types to languages other
> than PL/PgSQL
> -> Seems if someone needed this, they would say so (no thread).
>
> Add support for OUT and INOUT parameters to languages other than PL/PgSQL
> ->
On Sat, May 13, 2023 at 01:31:21AM -0400, Tom Lane wrote:
> John Naylor writes:
> > I've made another pass at this. Previously, I went one or two sections at a
> > time, but this time I tried just skimming the whole thing and noting what
> > jumps out at me. Also, I've separated things into three
John Naylor writes:
> I've made another pass at this. Previously, I went one or two sections at a
> time, but this time I tried just skimming the whole thing and noting what
> jumps out at me. Also, I've separated things into three categories: Remove,
> move to "not wanted list", and revise.
On Mon, Feb 6, 2023 at 11:04 AM John Naylor
wrote:
> I'll try to get back to culling the list items at the end of April.
I've made another pass at this. Previously, I went one or two sections at a
time, but this time I tried just skimming the whole thing and noting what
jumps out at me. Also,
On Mon, Jan 30, 2023 at 10:07 PM Bruce Momjian wrote:
>
> On Mon, Jan 30, 2023 at 01:13:45PM +0700, John Naylor wrote:
> > "It's worth checking if the feature of interest is found in the TODO
list on
> > our wiki: http://wiki.postgresql.org/wiki/TODO. The entries there often
have
> > additional
On Mon, Jan 30, 2023 at 01:13:45PM +0700, John Naylor wrote:
> On Tue, Jan 24, 2023 at 11:57 PM Bruce Momjian wrote:
> > I think we just point them at the TODO list and they will read the top
> > of the list first, no? I think you are right that we updated the top of
> > the TODO but didn't
On Tue, Jan 24, 2023 at 11:57 PM Bruce Momjian wrote:
>
> On Tue, Jan 24, 2023 at 10:46:34AM +0700, John Naylor wrote:
> >
> > https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F#TODOs
> > to:
> > "It's worth checking if the feature of interest is found in the TODO
list on
> >
On Tue, Jan 24, 2023 at 10:46:34AM +0700, John Naylor wrote:
>
> On Wed, Jan 18, 2023 at 3:13 AM Bruce Momjian wrote:
>
> > I think we risk overloading people with too many words above, and they
> > will not read it fully. Can it be simplified? I wonder if some of this
> > belows in the
On Wed, Jan 18, 2023 at 3:13 AM Bruce Momjian wrote:
> I think we risk overloading people with too many words above, and they
> will not read it fully. Can it be simplified? I wonder if some of this
> belows in the developer's FAQ and linked to that from the TODO list.
I think you're right.
On Mon, Jan 16, 2023 at 05:17:23PM +0700, John Naylor wrote:
>
> I wrote:
>
> > We could also revise the developer FAQ:
> > - remove phrase "Outstanding features are detailed in Todo."
> > - add suggestion to to check the Todo or Not_worth_doing pages to see if the
> desired feature is
On Wed, Jan 11, 2023 at 02:09:56PM +0700, John Naylor wrote:
> I've come up with some revised language, including s/15/16/ and removing the
> category of "[E]" (easier to implement), since it wouldn't be here if it were
> actually easy:
I think it is still possible for a simple item to be
I wrote:
> We could also revise the developer FAQ:
> - remove phrase "Outstanding features are detailed in Todo."
> - add suggestion to to check the Todo or Not_worth_doing pages to see if
the desired feature is undesirable or problematic
> - rephrase "Working in isolation is not advisable
So, I had intended to spend some time on this at least three times a year.
I've clearly failed at that, but now is as good a time as any to pick it
back up again.
Over in [1], Tom opined:
> John Naylor writes:
>
> > "WARNING for Developers: Unfortunately this list does not contain all
the
> >
On Wed, Dec 8, 2021 at 1:40 PM John Naylor wrote:
>
> It's been a while, but here are a few more suggested
> removals/edits/additions to the TODO list. Any objections or new
> information, let me know:
>
> - Auto-fill the free space map by scanning the buffer cache or by
> checking pages written
On Thu, Dec 9, 2021 at 2:40 AM John Naylor wrote:
>
> - Improve autovacuum tuning
> http://www.postgresql.org/message-id/5078ad6b.8060...@agliodbs.com
> http://www.postgresql.org/message-id/20130124215715.ge4...@alvh.no-ip.org
>
> I'm kind of on the fence about these. The title is way too broad,
It's been a while, but here are a few more suggested
removals/edits/additions to the TODO list. Any objections or new
information, let me know:
- Auto-fill the free space map by scanning the buffer cache or by
checking pages written by the background writer
On Thu, Jul 1, 2021 at 9:23 PM Bruce Momjian wrote:
> Agreed. Please remove them or I can do it.
Done, and also changed next release to "15".
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Jul 1, 2021 at 10:19 PM Thomas Munro wrote:
>
> Spotted in the "Hashing" section:
>
> "Use "lazy" hash tables to look up only the tuples that are actually
requested"
>
> David Rowley has knocked that one off. He called it Result Cache.
Thanks, I'll take care of that one also.
--
John
Spotted in the "Hashing" section:
"Use "lazy" hash tables to look up only the tuples that are actually requested"
David Rowley has knocked that one off. He called it Result Cache.
On Mon, Jun 28, 2021 at 05:41:50PM -0400, John Naylor wrote:
> Here I'm just reviewing a couple items in the Sorting section:
>
> https://wiki.postgresql.org/wiki/Todo#Sorting
>
> - Consider whether duplicate keys should be sorted by block/offset
>
>
Here I'm just reviewing a couple items in the Sorting section:
https://wiki.postgresql.org/wiki/Todo#Sorting
- Consider whether duplicate keys should be sorted by block/offset
https://www.postgresql.org/message-id/flat/23321.1205726381%40sss.pgh.pa.us
It's moot since we started requiring tid
On Wed, May 19, 2021 at 01:52:03PM -0400, John Naylor wrote:
> 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
>
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
On Thu, Dec 10, 2020 at 03:29:07PM -0400, John Naylor wrote:
> Hi,
I agree with all of your analysis, but have some feedback;
> Continuing with TODO list maintenance, first a couple things to clean up:
>
> - Allow ALTER INDEX ... RENAME concurrently
>
> This was in the wrong section, but it's
On Thu, Dec 10, 2020 at 3:29 PM John Naylor
wrote:
>
> *Views and Rules
> *SQL Commands
Hearing no objections, the items mentioned have been moved over.
--
John Naylor
EDB: http://www.enterprisedb.com
Hi,
Continuing with TODO list maintenance, first a couple things to clean up:
- Allow ALTER INDEX ... RENAME concurrently
This was in the wrong section, but it's irrelevant: The lock level was
lowered in commit 1b5d797cd4f, so I went ahead and removed this already.
- Add CORRESPONDING BY to
On Mon, Nov 23, 2020 at 10:41:25AM -0400, John Naylor wrote:
> With the exception of "Fix /contrib/btree_gist's implementation of inet
> indexing", all items above have been either moved over, or removed if they
> were
> done already by PG13.
Thanks.
--
Bruce Momjian
With the exception of "Fix /contrib/btree_gist's implementation of inet
indexing", all items above have been either moved over, or removed if they
were done already by PG13.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Nov 18, 2020 at 3:05 PM Tom Lane wrote:
> John Naylor writes:
> > Here are the next couple of sections with items proposed to be moved to
> the
> > "not worth doing" page. As before, if there are any objections, let me
> > know. I'll make the move in a few days.
>
> > - Fix
On Wed, Nov 18, 2020 at 2:42 PM Bruce Momjian wrote:
> On Wed, Nov 18, 2020 at 02:26:46PM -0400, John Naylor wrote:
> > Here are the next couple of sections with items proposed to be moved to
> the
> > "not worth doing" page. As before, if there are any objections, let me
> know.
> > I'll make
John Naylor writes:
> Here are the next couple of sections with items proposed to be moved to the
> "not worth doing" page. As before, if there are any objections, let me
> know. I'll make the move in a few days.
> - Fix /contrib/ltree operator
> Bug from 2007 with zero followup
Actually, I
On Wed, Nov 18, 2020 at 02:26:46PM -0400, John Naylor wrote:
> Here are the next couple of sections with items proposed to be moved to the
> "not worth doing" page. As before, if there are any objections, let me know.
> I'll make the move in a few days.
>
> Also, since 13 has been released, I'll
Here are the next couple of sections with items proposed to be moved to the
"not worth doing" page. As before, if there are any objections, let me
know. I'll make the move in a few days.
Also, since 13 has been released, I'll change the explanation of Done items
to "will appear in the PostgreSQL
On Wed, Nov 11, 2020 at 4:45 PM John Naylor
wrote:
> Here is the next section on data types, proposed to be moved to the "not
> worth doing" page. As before, if there are any objections, do speak up.
> I'll make the move in a few days.
>
Hearing no objection, these have been moved over.
--
Here is the next section on data types, proposed to be moved to the "not
worth doing" page. As before, if there are any objections, do speak up.
I'll make the move in a few days.
**Datatypes
- Fix data types where equality comparison is not intuitive, e.g. box
There is likely no way to do this
On Tue, Nov 10, 2020 at 7:08 PM Bruce Momjian wrote:
> On Tue, Nov 3, 2020 at 02:06:13PM -0400, John Naylor wrote:
> > I was thinking of not having the next updates during commitfest, but it
> could
> > also be argued this is a type of review, and the things here will be
> returned
> > with
On Tue, Nov 3, 2020 at 02:06:13PM -0400, John Naylor wrote:
> I was thinking of not having the next updates during commitfest, but it could
> also be argued this is a type of review, and the things here will be returned
> with feedback or rejected, in a way. Ultimately, it comes down to "when
I wrote:
>
> Ok, that's two votes for a separate page, and one for a new section on the
> same page, so it looks like it's a new page. That being the case, I would
> think it logical to move "features we don't want" there. As for the name,
> we should probably encompass both "won't fix" bugs and
On Wed, Oct 28, 2020 at 1:57 PM Andres Freund wrote:
> On 2020-10-28 16:20:03 +0100, Magnus Hagander wrote:
> > I would personally prefer a completely seprate page
>
> Same.
>
Ok, that's two votes for a separate page, and one for a new section on the
same page, so it looks like it's a new page.
On 2020-10-28 16:20:03 +0100, Magnus Hagander wrote:
> I would personally prefer a completely seprate page
Same.
On Wed, Oct 28, 2020 at 3:35 PM Julien Rouhaud wrote:
>
> On Wed, Oct 28, 2020 at 9:27 PM John Naylor
> wrote:
> >
> > On Wed, Oct 28, 2020 at 6:52 AM Magnus Hagander wrote:
> >>
> >> On Wed, Oct 28, 2020 at 11:15 AM Julien Rouhaud wrote:
> >> >
> >> > On Wed, 28 Oct 2020, 17:55 Oleksandr
On Wed, Oct 28, 2020 at 9:27 PM John Naylor
wrote:
>
> On Wed, Oct 28, 2020 at 6:52 AM Magnus Hagander wrote:
>>
>> On Wed, Oct 28, 2020 at 11:15 AM Julien Rouhaud wrote:
>> >
>> > On Wed, 28 Oct 2020, 17:55 Oleksandr Shulgin > > wrote:
>> >> I'm totally on board with cleaning the list up, but
On Wed, Oct 28, 2020 at 6:52 AM Magnus Hagander wrote:
> On Wed, Oct 28, 2020 at 11:15 AM Julien Rouhaud
> wrote:
> >
> > On Wed, 28 Oct 2020, 17:55 Oleksandr Shulgin <
> oleksandr.shul...@zalando.de wrote:
> >> I'm totally on board with cleaning the list up, but how about marking
> as "won't
On Tue, Oct 27, 2020 at 6:05 PM Bruce Momjian wrote:
> On Tue, Oct 27, 2020 at 04:54:24PM -0400, John Naylor wrote:
> >
> >
> > On Tue, Oct 27, 2020 at 3:52 PM Bruce Momjian wrote:
> >
> >
> > Do any of these limitations need to be documented before removing
> them
> > from the TODO
On Wed, Oct 28, 2020 at 11:15 AM Julien Rouhaud wrote:
>
> On Wed, 28 Oct 2020, 17:55 Oleksandr Shulgin wrote:
>>
>> On Tue, Oct 27, 2020 at 8:25 PM John Naylor
>> wrote:
>>>
>>> As I mentioned in [1], I've volunteered to clear out the TODO list of items
>>> that appear to be too difficult,
On Wed, 28 Oct 2020, 17:55 Oleksandr Shulgin On Tue, Oct 27, 2020 at 8:25 PM John Naylor
> wrote:
>
>> As I mentioned in [1], I've volunteered to clear out the TODO list of
>> items that appear to be too difficult, controversial, or otherwise not
>> worth doing to warrant being listed there.
On Tue, Oct 27, 2020 at 8:25 PM John Naylor
wrote:
> As I mentioned in [1], I've volunteered to clear out the TODO list of
> items that appear to be too difficult, controversial, or otherwise not
> worth doing to warrant being listed there. I'll be working a few sections
> at a time, and every
On Tue, Oct 27, 2020 at 04:54:24PM -0400, John Naylor wrote:
>
>
> On Tue, Oct 27, 2020 at 3:52 PM Bruce Momjian wrote:
>
>
> Do any of these limitations need to be documented before removing them
> from the TODO list?
>
>
> I see two areas that might use a mention:
>
> -
On Tue, Oct 27, 2020 at 3:52 PM Bruce Momjian wrote:
>
> Do any of these limitations need to be documented before removing them
> from the TODO list?
>
I see two areas that might use a mention:
- pg_settings not displaying custom variables
- SQL standard difference with REVOKE ROLE (I haven't
On Tue, Oct 27, 2020 at 4:00 PM Thomas Munro wrote:
> On Wed, Oct 28, 2020 at 8:36 AM Andres Freund wrote:
> > On 2020-10-27 15:24:35 -0400, John Naylor wrote:
> > > - Allow WAL replay of CREATE TABLESPACE to work when the directory
> > > structure on the recovery computer is different from the
On Wed, Oct 28, 2020 at 8:36 AM Andres Freund wrote:
> On 2020-10-27 15:24:35 -0400, John Naylor wrote:
> > - Allow WAL replay of CREATE TABLESPACE to work when the directory
> > structure on the recovery computer is different from the original
> > Thread quote: "part of the difficult,
On Tue, Oct 27, 2020 at 03:46:14PM -0400, Bruce Momjian wrote:
> On Tue, Oct 27, 2020 at 03:24:35PM -0400, John Naylor wrote:
> > As I mentioned in [1], I've volunteered to clear out the TODO list of items
> > that appear to be too difficult, controversial, or otherwise not worth
> > doing to
> >
On Tue, Oct 27, 2020 at 03:24:35PM -0400, John Naylor wrote:
> As I mentioned in [1], I've volunteered to clear out the TODO list of items
> that appear to be too difficult, controversial, or otherwise not worth doing
> to
> warrant being listed there. I'll be working a few sections at a time,
Hi,
On 2020-10-27 15:24:35 -0400, John Naylor wrote:
> As I mentioned in [1], I've volunteered to clear out the TODO list of items
> that appear to be too difficult, controversial, or otherwise not worth
> doing to warrant being listed there. I'll be working a few sections at a
> time, and every
As I mentioned in [1], I've volunteered to clear out the TODO list of items
that appear to be too difficult, controversial, or otherwise not worth
doing to warrant being listed there. I'll be working a few sections at a
time, and every so often I'll have a list of proposed items for removal. If
I
65 matches
Mail list logo
