On Wed, 30 Jul 2025 at 00:57, Tom Lane wrote:
>
> David Rowley writes:
> > On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut wrote:
> >> Note that gcc and clang switched to C11 by default a long time ago
> >> (gcc-5 and clang-3.6), so for most users all these tests
On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut wrote:
> Note that gcc and clang switched to C11 by default a long time ago
> (gcc-5 and clang-3.6), so for most users all these tests won't need to
> do anything. If you want to test it, you could simulate an older
> default like
>
> ./configure CC=
On Fri, 25 Jul 2025 at 06:46, Cary Huang wrote:
> Thank you so much for the review! I have addressed the comments in the
> attached v7 patch.
I've now spent quite a bit of time going over this patch and testing
it. One issue I found was in heap_set_tidrange() where you were not
correctly setting
On Tue, 29 Jul 2025 at 16:01, Richard Guo wrote:
> Another possible direction is to support runtime plan correction or
> feedback loops. We've always followed a "plan-first, execute-next"
> approach so far. But perhaps we could extend that by monitoring plan
> execution and triggering re-optimiz
On Wed, 23 Jul 2025 at 23:08, Ilia Evdokimov
wrote:
> Given that, patch v11 still looks like the most appropriate version to me.
I spent a bit more time cleaning a few things up in this. With all the
complexity from the extra fields, I felt that a round of adjusting the
"double" types so they use
On Tue, 29 Jul 2025 at 12:11, Matheus Alcantara
wrote:
> By "pushdowns" you mean missing the Run Conditions on the QUALIFY
> example? IIUC the Run Condition is only created if it's a subquery. I've
> checked this on set_rel_size() -> set_subquery_pathlist() ->
> check_and_push_window_quals().
Yes
On Mon, 28 Jul 2025 at 20:13, Richard Guo wrote:
> create table t (a int, b int, c int);
> insert into t select i%3, i, i from generate_series(1,500)i;
> analyze t;
>
> explain (analyze, costs off, timing off)
> select * from t t1 join lateral
> (select t2.a, t2.b, t1.a x from t t2, t t3 offset
On Thu, 24 Jul 2025 at 12:27, Tom Lane wrote:
> Hmmm ... but you did check that in fact we can remove such known-dead
> code and not get a warning now?
Yes. The patch has a small temporary adjustment to
BaseBackupGetTargetHandle() to comment out the return. It compiles for
me using Visual Studio
(Moving this discussion to hackers. Previously in [0].)
Background:
The ereport_domain() macro has a pg_unreachable() which is meant to be
hit when the elevel >= ERROR so that the compiler can determine that
elog/ereport ERROR never returns. This works fine in gcc and clang but
MSVC seems to be u
On Thu, 24 Jul 2025 at 08:52, Greg Hennessy wrote:
> Adding a new enum to solve a perceived problem doesn't seem like a large
> ask to me.
Seems overly slow to me. As someone has to write the patch, a
committer has to commit said patch, the user must wait for the next
major version to be released
On Mon, 21 Jul 2025 at 06:27, Greg Hennessy wrote:
> test=# show parallel_worker_algorithm ;
> parallel_worker_algorithm
> ---
> log3
> (1 row)
I don't think having a GUC which allows exactly two settings is
anywhere near as flexible as you could make this. You're compla
On Wed, 23 Jul 2025 at 02:35, Andrei Lepikhov wrote:
> The 'Buffers:' way looks more natural to me. I don't like duplicated
> text in the explain format - it is already cluttered by multiple
> unnecessary elements that distract attention from the problematic plan
> elements, such as unplaggable co
On Wed, 23 Jul 2025 at 11:06, Tom Lane wrote:
>
> David Rowley writes:
> > I'm currently thinking we should just fix the pgmkdirp.c instance and
> > call it good.
>
> +1
Done.
David
On Wed, 23 Jul 2025 at 10:36, Tom Lane wrote:
>
> David Rowley writes:
> > Looking at [1], it seems even ancient versions of gcc and clang
> > rewrite the strstr() into a strchr() call when the search term is a
> > single char string. So it might not be worth doing to any
On Tue, 22 Jul 2025 at 05:16, Sami Imseih wrote:
> Also, I'd like to ask. what would be the argument against offering both
> options,
> ALTER and a GUC to override the catalog, as currently proposed in the patch?
For me, the reason I don't like ALTER TABLE + the use_invisible_index
/ force_invis
On Wed, 23 Jul 2025 at 09:21, Vik Fearing wrote:
> I took a quick look at the patch (without applying and testing it) and
> it seems to me that parse analysis is the wrong place to do this. We
> want ruleutils to be able to spew out the QUALIFY clause as written in a
> view and not as transformed.
On Wed, 23 Jul 2025 at 09:34, Dmitry Mityugov wrote:
> Thank you for your attention to this problem. The code in
> contrib/fuzzystrmatch/dmetaphone.c indeed uses several calls to strstr()
> to search for a single character, but it also uses strstr() to search
> for strings that consist of more tha
On Tue, 22 Jul 2025 at 10:20, Jacob Champion
wrote:
>
> On Fri, Dec 13, 2024 at 12:54 AM Alexander Kuznetsov
> > 1. slot2 is NULL at line 968,
> > 2. The while loop at line 971 executes once, filling slot1 (slot2 still
> > remains NULL),
> > 3. No changes occur to slot2 thereafter, up to line 100
On Tue, 10 Jun 2025 at 11:04, Cary Huang wrote:
> I have addressed your comment in the attached v6 patch. Thank you again for
> the review.
Here's a review of v6:
1. In cost_tidrangescan() you're dividing the total costs by the
number of workers yet the comment is claiming that's CPU cost. I thi
On Fri, 4 Jul 2025 at 20:30, Ilia Evdokimov
wrote:
> I attached rebased v10 patch on 5a6c39b.
I've gone over this and made some cosmetic adjustments. A few
adjustments to the comments and used Cardinality rather than double
for some data types. I also moved the MemoizePath.calls field down
below
On Fri, 18 Jul 2025 at 14:25, Sami Imseih wrote:
> I’d argue we should not provide the ALTER option without the GUC, for
> more granular control.
If you mean the use_invisible_index GUC, then for transparency here,
I'm not in favour of that. I do understand that this might be useful
when trying t
On Fri, 18 Jul 2025 at 13:04, David G. Johnston
wrote:
> Have the planner produce two numbers.
>
> 1: This plan needs a minimum of N workers to make the parallelism worthwhile.
> Assume that is what we produce today.
> 2: A number representing how much this plan would benefit from the
> availa
On Wed, 16 Jul 2025 at 05:59, Robert Treat wrote:
> operational risk within the system. Similarly, the nature of the DDL
> change also requires that all sessions be impacted everywhere at once;
> there is no way to slowly roll the change to some segment of the
> database or some specific workload
On Fri, 18 Jul 2025 at 05:03, Andres Freund wrote:
> Right now we basically assume that the benefit of parallelism reduces
> substantially with every additional parallel worker, but for things like
> seqscans that's really not true. I've seen reasonably-close-to-linear
> scalability for parallel
On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
> workers, but there isn't an easy way to get more
> workers.
Is "alter table ... set (parallel_workers=N);" not easy enough?
David
On Sat, 14 Jun 2025 at 19:04, David Rowley wrote:
> I propose I just push the fix_idea.patch and leave it at that for v18.
>
> Does anyone have any other ideas?
I've now pushed that as a fix.
David
On Wed, 11 Jun 2025 at 20:37, Tatsuro Yamada wrote:
> I created a regression test to check the enable_groupagg parameter in
> the new patch.
> To ensure plan stability, I disabled parallel query by setting the
> max_parallel_*
> parameters to 0.
>
> Any feedback is welcome.
Typically, in the reg
On Sat, 7 Jun 2025 at 23:00, Alexander Lakhin wrote:
> #5 0x5dd0a1788377 in ExceptionalCondition (conditionName=0x5dd0a1822ee8
> "memcmp(&tmp, cattr, sizeof(CompactAttribute)) == 0",
> fileName=0x5dd0a1822ed9 "tupdesc.c", lineNumber=165) at assert.c:66
Thanks for finding that and for th
On Sat, 14 Jun 2025 at 16:10, Junwang Zhao wrote:
>
> On Sat, Jun 14, 2025 at 11:27 AM David Rowley wrote:
> > How about adding "We don't bother validating that trss_mintid is less
> > than or equal to trss_maxtid, as the scan_set_tidrange() table AM
> > func
On Wed, 11 Jun 2025 at 14:26, Junwang Zhao wrote:
> This is not a common case, it's just a corner case while
> playing around the TidRangeScan.
>
> I'm not saying this is an optimization, it just makes me a little
> confused when I see the lowerBound > upperBound and
> it still returns true.
>
> T
On Tue, 10 Jun 2025 at 04:40, Robert Treat wrote:
> You are going to have a guc either way, which
> means you are going to have to explain a bunch of these different
> caveats in BOTH solutions. It's just that in one of the solutions, you
> are further entangling the usage with DDL changes (and th
On Sun, 8 Jun 2025 at 21:41, Junwang Zhao wrote:
> The comments of TidRangeEval saids:
>
> ```
> Returns false if we detect the range cannot contain any tuples.
> ```
>
> After narrowing the upper and lower bounds, we can add an
> additional check to verify if the lower bound exceeds the
> upper b
On Mon, 9 Jun 2025 at 06:53, Robert Treat wrote:
>
> On Sat, Jun 7, 2025 at 9:17 PM David Rowley wrote:
> > What are your thoughts on cached plans? In this scenario, do you
> > assume that waiting a few days means that connections get reset and
> > prepared statements
On Sun, 8 Jun 2025 at 01:35, Robert Treat wrote:
>
> On Fri, Jun 6, 2025 at 8:04 PM David Rowley wrote:
> > Can you list your proposed series of steps you'd recommend to a DBA
> > wishing to remove an index, assuming this feature exists in core as
> > you'd li
On Fri, 6 Jun 2025 at 14:32, Robert Treat wrote:
> In production, you aren't watching to see what happen with
> pg_stat_all_indexes, because you will first be watching pg_stat_activity to
> see if the plans have flipped in some way that leads to an overloaded server
> (extra latency, poor cachi
On Fri, 6 Jun 2025 at 08:14, Robert Treat wrote:
> I know this thread is rather old and there doesn't seem to be full
> agreement on the ALTER vs GUC implementation idea, and even though I
> agree with the sentiment that the GUC system is little more than the
> "half-baked take on planner hints",
On Fri, 6 Jun 2025 at 07:49, Ayush Vatsa wrote:
> That said, I’m wondering if this might not be necessary, given that
> Gather Merge already accomplishes similar functionality. Would
> love to hear your thoughts on whether there’s a distinct advantage to
> adding parallelism to Merge Append or if
On Fri, 6 Jun 2025 at 01:47, Ayush Vatsa wrote:
> A small follow-up question - Gather merge won't gather and merge the
> output from child in sorted order, but will always need an explicit Sort
> node beneath it to do so. Correct?
Incorrect. The input node to the Gather Merge needs to be sorted b
On Thu, 5 Jun 2025 at 07:31, Ayush Vatsa wrote:
> Are these Index Scans executed sequentially (one after the other as the Merge
> Append requests tuples)?
It's a fairly simple answer: Merge Append does not support parallelism.
> Or are they possibly executed in parallel, in advance, or concurre
On Thu, 29 May 2025 at 16:28, Fujii Masao wrote:
> I agree with changing the default value of auto_explain.log_buffers to true.
> I think that users who know EXPLAIN ANALYZE includes buffers info in
> the result by default since v18 would expect the buffer info also to
> be included in auto_explai
On Fri, 30 May 2025 at 23:31, Zhou, Zhiguo wrote:
> Please review this patch for consideration in upcoming PostgreSQL releases.
Please add the patch to https://commitfest.postgresql.org/53/
David
On Fri, 30 May 2025 at 11:51, David Rowley wrote:
>
> On Fri, 30 May 2025 at 11:35, Michael Paquier wrote:
> > Thanks, Nathan. Let's proceed with the change then. David, would you
> > prefer handling the patch you have written by yourself for the query
> > ID par
Thanks for the review.
On Wed, 21 May 2025 at 03:35, Sami Imseih wrote:
> 2/ Should "DatumGetInt64(hash_any_extended(.." be turned into a
> macro since it's used in
> several places? Also, we can add a comment in the macro such as
> "
> Output the queryId as an int64 rather than a uint64, to
On Fri, 30 May 2025 at 11:35, Michael Paquier wrote:
> Thanks, Nathan. Let's proceed with the change then. David, would you
> prefer handling the patch you have written by yourself for the query
> ID part?
Yes. I'll look at that again shortly.
David
On Wed, 28 May 2025 at 11:24, John Naylor wrote:
> https://lemire.me/blog/2025/04/13/detect-control-characters-quotes-and-backslashes-efficiently-using-swar/
>
> I don't find this use of SWAR that bad for readability, and there's
> only one obtuse clever part that merits a comment. Plus, it seems
On Mon, 26 May 2025 at 18:08, Yugo Nagata wrote:
> While building PostgreSQL 17 on Windows, I noticed bitcode files (.bc) are not
> generated with meson. Does this means that "inlining" of JIT doesn't
> work when PostgreSQL is build with meson?
Yes. I believe [1] aims to fix this.
David
[1] ht
On Thu, 22 May 2025 at 02:58, Peter Eisentraut wrote:
>
> On 20.05.25 08:38, Michael Paquier wrote:
> > On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
> >> Given the planId stuff is new and has the same issue, I think that
> >> pushes me towards thi
On Tue, 20 May 2025 at 18:12, Julien Rouhaud wrote:
> I don't think it was discussed, but why not go the other way, keep everything
> as uint64 and expose an uint64 datatype at the SQL level instead? That's
> something I actually want pretty often so I would be happy to have that
> natively, whet
On Tue, 20 May 2025 at 16:07, Tom Lane wrote:
> Failures like this one [1]:
>
> @@ -340,9 +340,13 @@
> create function myinthash(myint) returns integer strict immutable language
>internal as 'hashint4';
> NOTICE: argument type myint is only a shell
> +ERROR: ROWS is not applicable when fun
On Tue, 20 May 2025 at 17:09, Michael Paquier wrote:
>
> On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> > Yeah, +1 to making this consistent across both query ID and the new plan
> > ID, and changing both to int64 internally seems best.
>
> Any thoughts from others? I'm OK to take
On Sat, 17 May 2025 at 01:19, Andres Freund wrote:
> @@ -42,7 +42,7 @@
> -> Nested Loop (actual rows=1000.00 loops=N)
> -> Seq Scan on tenk1 t2 (actual rows=1000.00 loops=N)
> Filter: (unique1 < 1000)
> - Rows Removed by Filter: 9000
> +
On Tue, 20 May 2025 at 03:05, Peter Eisentraut wrote:
> Or why not store query IDs as int64_t
> internally, too?
I had the same thought. Changing to int64 seems like a good and less
bug-prone tidy-up. I expected we ended up with uint64 as the previous
type was uint32, and uint64 is the natural se
On Tue, 13 May 2025 at 04:03, Richard Guo wrote:
> While adding a new field to PlannerGlobal in another patch, I noticed
> that although most fields are explicitly initialized, a few are not.
> This doesn't cause any functional issues, since makeNode() zeroes all
> fields by default. However, the
On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> I will continue improving it until beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Minor detail, but "Improve the performance and reduce memory usage of
hash joins and GROUP BY" proba
On Thu, 8 May 2025 at 15:23, David G. Johnston
wrote:
> Not liking the proposal, not sure it is even correct. Somehow "children of
> inheritance parent tables" are omitted.
I don't see the quoted text anywhere in this area, so I'm not sure I
follow what you mean with the omission.
> In both c
On Thu, 8 May 2025 at 13:11, Bruce Momjian wrote:
> Ah, I see those now. It was two commits. For some reason the edits are
> hard for me; applied patch attached.
Thanks. There's been lots of work done in the last year, so lots of
work to understand it all to a level where you can write meanin
On Thu, 8 May 2025 at 12:36, Bruce Momjian wrote:
> +Change pg_backend_memory_contexts.level and
> pg_log_backend_memory_contexts()() to be one-based (Melih Mutlu, Fujii Masao)
There's an extra set of parentheses on that function name. There's
also an inconsistency between the commit link you ad
In [1] there's a bug report about ALTER TABLE ... ALTER COLUMN SET
(n_distinct = N) not working for partitioned tables. Of course, you
need to use n_distinct_inherited for partitioned tables, but the docs
don't say that.
I went through a few iterations of the wording to make this clearer
and lande
On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> You can see the most current HTML-built version here:
>
> https://momjian.us/pgsql_docs/release-18.html
You might have left it out on purpose as the output isn't likely to be
read by a machine, but for "Change pg_backend_memory_contexts.
On Wed, 7 May 2025 at 13:17, Bruce Momjian wrote:
>
> On Wed, May 7, 2025 at 09:27:14AM +1200, David Rowley wrote:
> > On Wed, 7 May 2025 at 07:44, Bruce Momjian wrote:
> > A query such as: SELECT * FROM table_with_lots_of_partitions ORDER BY
> > col; will plan much fa
On Wed, 7 May 2025 at 07:44, Bruce Momjian wrote:
> I think what you are saying is that this has to do with partition
> processing of joins, but not the pruning process. I don't think a
> non-partition joins are likely to hit 32 EquivalenceClasses.
A query such as: SELECT * FROM table_with_lots_
On Tue, 6 May 2025 at 03:59, Bruce Momjian wrote:
>
> On Mon, May 5, 2025 at 09:42:10PM +1200, David Rowley wrote:
> > I agree that 88f55bc97 and d69d45a5a should be in their own item.
> > Likely no need to go into detail about the speed up being about
> > "Equival
On Fri, 2 May 2025 at 14:44, Bruce Momjian wrote:
> You can see the most current HTML-built version here:
>
> https://momjian.us/pgsql_docs/release-18.html
Thanks for working on these.
For "Improve the performance of hash joins (David Rowley)", 0f5738202
did the same
On Fri, 2 May 2025 at 16:01, Amit Langote wrote:
> +Allow partitions to be pruned earlier and quicker, and skipped in
> more places (Amit Langote, Ashutosh Bapat, Yuya Watari, David Rowley)
>
> Alternatively, 2 and 3 can be combined as:
> 2. Speed up partition planni
On Thu, 1 May 2025 at 17:35, Junwang Zhao wrote:
>
> On Thu, May 1, 2025 at 8:12 AM David Rowley wrote:
> > It sounds like the aim is to fix the problem with autovacuum vacuuming
> > the same table over and over and being unable to remove enough dead
> > tuples due to so
On Thu, 1 May 2025 at 03:29, Nathan Bossart wrote:
> That being said, I am -1 for this proposal. Autovacuum parameters and
> scheduling are already quite complicated, and making it nondeterministic
> would add an additional layer of complexity (and may introduce its own
> problems). But more imp
On Wed, 30 Apr 2025 at 19:13, Fujii Masao wrote:
> This commit seems to have caused an indent-check failure on the buildfarm
> member koel.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=koel&dt=2025-04-30%2002%3A19%3A00
Thanks. Fixed.
David
On Wed, 30 Apr 2025 at 13:25, Junwang Zhao wrote:
> Found a trivial typo in multixact.c, after searching the code base
> there is another such typo in jsonfuncs.c.
Thanks. Pushed.
David
On Sun, 27 Apr 2025 at 08:44, Tomas Vondra wrote:
> Thanks. Those changes seem fine to me to.
Thanks for checking.
> Do you intend to push these, or do you want me to do it?
I made a few tweaks to the comments and pushed.
David
On Thu, 24 Apr 2025 at 21:27, Japin Li wrote:
> I propose that PostgreSQL prevent redundant index creation by:
>
> - Checking for identical existing indexes during CREATE INDEX.
> - Failing with an error (like Oracle's ORA-01408) if a duplicate is found.
> - Providing a GUC parameter (allow_redund
On Tue, 22 Apr 2025 at 12:27, David G. Johnston
wrote:
> On Monday, April 21, 2025, David Rowley wrote:
>> Does anyone have any opinion on the wording I'm proposing in the attached?
>
> I like it. It removes the problematic wording and moves the reference to
> —all clo
On Tue, 22 Apr 2025 at 08:53, Noboru Saito wrote:
> Regarding "to to" and "that that", I agree that they might be
> technically acceptable.
> However, I personally find them a bit harder to parse and they
> increase the chance of misreading for me.
> Your suggested alternative for "to to" is much
On Mon, 21 Apr 2025 at 15:06, Noboru Saito wrote:
> 1. Remove unnecessary blank lines (blankline.diff)
Looks good.
> 2. Fix repeated "to to" in several command reference files (toto.diff)
-Specifies the name of the database to connect to to discover which
+Specifies the name of
On Mon, 21 Apr 2025 at 11:21, Michael Paquier wrote:
> Thanks for sharing the command able to spot all these.
I just pushed a few more. The previous regex didn't account for the
duplicate word being on the next line. I dug up the following to find
the ones just committed in 78eda9e26.
ag "\s([a-
On Sun, 20 Apr 2025 at 13:32, David Rowley wrote:
> Here are a few more fixes of a similar ilk. All new in 2025,
> predominantly from the last few days before feature freeze.
I've pushed those ones.
David
On Sat, 19 Apr 2025 at 20:00, Alexander Lakhin wrote:
> I've gathered the following collection of typos and inconsistencies
> appeared since 2025-01-01:
Here are a few more fixes of a similar ilk. All new in 2025,
predominantly from the last few days before feature freeze.
The few I wasn't a ful
On Fri, 18 Apr 2025 at 20:54, Fujii Masao wrote:
> Shouldn't the example output of pg_log_backend_memory_contexts() in
> the documentation also be updated to use 1-based numbering for consistency?
> Patch attached.
Yeah. I failed to notice we had an example of the output.
Want to take care of it
On Fri, 18 Apr 2025 at 00:25, Rahila Syed wrote:
> Regarding v2 patch,
> - int level = 0;
>
> Retaining the level variable will enhance the code readability, IMO.
When I read that, I suspected it might have been leftover from a
refactor during the develop
On Wed, 16 Apr 2025 at 10:09, Ilia Evdokimov
wrote:
> I've prepared the updated patches as discussed, including the addition
> of estimated lookups in the EXPLAIN output for Memoize. Please let me
> know if you have any feedback or further suggestions.
While this is fresh, as I might forget befor
On Thu, 17 Apr 2025 at 19:50, Daniel Gustafsson wrote:
> > On 17 Apr 2025, at 01:44, David Rowley wrote:
> > 1) Commit the attached to master
> > 2) Do nothing.
> >
> > I'd like to do #1.
>
> I vote for #1 as well.
Thanks for the judgment sense check. I
On Sat, 12 Apr 2025 at 07:33, Sami Imseih wrote:
> What do you think of the attached?
I looked at the v3 patch and I'm having trouble getting excited about it.
I'd say this part is misleading:
@@ -3956,7 +3961,8 @@ description | Waiting for a newly initialized
WAL file to reach durable storage
On Mon, 14 Apr 2025 at 19:39, David Rowley wrote:
> 1) I should commit the attached 0002 patch now, or;
> 2) Should commit only the new-to-v18 ones now, or;
> 3) do nothing.
>
> I think #3 isn't a good option as we (or I) have made efforts in the
> past to keep these in
On Thu, 17 Apr 2025 at 02:20, torikoshia wrote:
> Regarding the implementation:
> In the initial patch attached, I naïvely incremented the level just
> before emitting the log line.
> However, it might be cleaner to simply initialize the level variable to
> 1 from the start. This could help avoid
On Wed, 16 Apr 2025 at 01:23, torikoshia wrote:
>=# select name, level from pg_backend_memory_contexts;
> name | level
>+---
> TopMemoryContext | 1
>=# select pg_log_backend_memory_contexts(pg_backend_pid());
On Wed, 16 Apr 2025 at 04:25, Robert Haas wrote:
>
> On Mon, Apr 14, 2025 at 8:23 PM David Rowley wrote:
> > "Estimates: capacity=N distinct keys=N lookups=N hit ratio=N.N%"
>
> Is lookups=N here the estimated number of lookups i.e. what we think
> nloops will end
On Tue, 15 Apr 2025 at 21:44, Ilia Evdokimov
wrote:
> Wrapping the line in costs or verbose would help with test stability, but
> doing that only to simplify test output doesn't look like the right reason.
> Maybe it makes more sense to mask these values in other tests that use
> Memoize too. W
On Tue, 15 Apr 2025 at 11:14, Ilia Evdokimov
wrote:
> On 14.04.2025 23:53, David Rowley wrote:
> If we can't get consensus for everything people want to add at once
> then maybe the patch could be broken into two, with 0001 being pretty
> much the v4 patch and then have 0002 add
On Tue, 15 Apr 2025 at 04:31, Robert Haas wrote:
> I don't think we should use ANALYZE for this because, IME, that should
> just be about whether the query gets executed. Since this looks like
> information that is available at plan time, I think it should be
> displayed all the time or made conti
In a similar effort to what I did in [1], there's a bunch of
appendPQExpBuffer() calls that could use appendPQExpBufferStr() or
appendPQExpBufferChar(). With [1], I've been keeping those
appendStringInfo calls in check at this time of year for a few years
now. With appendPQExpBuffer I've not been,
I noticed a while ago that the new fast-path locking code uses integer
division to figure out the fast-path locking group slot. To me, this
seems a bit unnecessary as FastPathLockGroupsPerBackend is always a
power-of-two value, so we can use bitwise-AND instead.
I don't think FAST_PATH_REL_GROUP
On Sat, 12 Apr 2025 at 20:29, Corey Huinker wrote:
>>
>> at the *actual size* of the relation and takes that into account when
>> scaling the statistics (see table_block_relation_estimate_size() in
>> tableam.c). If the table sizes don't match between the two servers
>> then there's no guarantees
On Fri, 11 Apr 2025 at 02:01, Sami Imseih wrote:
> I created an entry for the July CF
> https://commitfest.postgresql.org/patch/5691/
>
> ... and I realized I forgot to include David's code comment patch yesterday,
> Reattaching both patches.
I've pushed the code comment patch.
For the docs patc
On Mon, 7 Apr 2025 at 19:39, Melanie Plageman wrote:
> +++
> C:/cirrus/build/testrun/pg_upgrade/002_pg_upgrade/data/results/subselect.out
> 2025-04-04 14:47:20.358393500 +
> @@ -2769,15 +2769,16 @@
> EXPLAIN (COSTS OFF)
> SELECT c.oid,c.relname FROM pg_class c JOIN pg_am a USING (oid)
> WH
On Fri, 11 Apr 2025 at 02:51, Nathan Bossart wrote:
> This probably isn't v18 material, but this reminds me of my idea to change
> appendStringInfoString() into a macro for appendBinaryStringInfo() so that
> the compiler can remove the runtime strlen() calls for string literals [0].
> In most case
On Thu, 10 Apr 2025 at 20:24, Heikki Linnakangas wrote:
>
> On 10/04/2025 06:51, David Rowley wrote:
> > Any objections to doing this soonish? Or in a few weeks?
>
> Sure, let's do it. Why would we wait?
Great. Pushed. Was considering waiting as I didn't know if the
On Thu, 10 Apr 2025 at 18:05, Dianjin Wang wrote:
> Here is a patch to add the `.DS_Store` to the .gitignore to ignore the
> `.DS_Store` file tracking by git when doing some development work in
> the macOS terminal. It helps me and my community (Apache Cloudberry) a
> lot. I hope this small patch
On Thu, 10 Apr 2025 at 02:18, Tom Lane wrote:
> If we did want to do something about this warning, rather than
> hacking up the call sites I'd be inclined to invent something like
> "bms_first_member()" which does the same thing but additionally
> asserts on empty input. Not really convinced it's
On Thu, 10 Apr 2025 at 16:57, Amit Langote wrote:
>
> On Thu, Apr 10, 2025 at 12:03 PM David Rowley wrote:
> > -Most operations on EquivalenceClasses should ignore child members.
> > +Most operations on EquivalenceClasses needn't look at child members.
> >
> >
Looks like v18 has grown a few appendStringInfo misusages, e.g. using
appendStringInfo() when no formatting is needed or just using format
"%s" instead of using appendStringInfoString().
I've attached a couple of patches. The 0001 is just my method for
finding these, not for commit. 0002 contains
On Wed, 9 Apr 2025 at 17:38, Amit Langote wrote:
> Still, maybe a tiny tweak to the last line could help steer readers
> right without diving into storage. How about:
>
> Most operations on EquivalenceClasses should ignore child members,
> which are stored separately from normal members.
I think
1 - 100 of 1612 matches
Mail list logo
