ch success and few reverts.
Congratulations to all!
--
John Naylor
EDB: http://www.enterprisedb.com
ackground_psql doesn't look like other ones that have "key
=> value". Is there something I'm missing?
--
John Naylor
EDB: http://www.enterprisedb.com
relevant list functions show up.
--
John Naylor
EDB: http://www.enterprisedb.com
but will look more closely as time permits.
(Side note: My personal preference for rough doc patches would be to leave
out spurious whitespace changes. That not only includes indentation, but
also paragraphs where many of the words haven't changed at all, but every
line has changed to keep the paragraph tidy. Seems like more work for both
the author and the reviewer.)
--
John Naylor
EDB: http://www.enterprisedb.com
ored in single pg_largeobjects relation
I would just say "also limited by relation size".
(note: Our catalogs are named in the singular.)
--
John Naylor
EDB: http://www.enterprisedb.com
ands/vacuum.c:2236
#8 0x0069c594 in vacuum (relations=0x14dde38,
params=0x7ffec2858850, bstrategy=0x14ddca8, vac_context=0x14ddb90,
isTopLevel=) at ../src/backend/commands/vacuum.c:623
[1]
https://www.postgresql.org/message-id/CAD21AoAyYBZOiB1UPCPZJHTLk0-arrq5zqNGj%2BPrsbpdUy%3Dg-g%40mail.gmail.com
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Apr 27, 2023 at 9:12 PM Daniel Gustafsson wrote:
>
> > On 27 Apr 2023, at 16:06, Masahiko Sawada wrote:
> > On Fri, Apr 21, 2023 at 12:02 PM John Naylor
> > wrote:
>
> >> ...that call to background_psql doesn't look like other ones that have
making a long hint
even longer doesn't seem worth doing. I'd like to set that aside and come
back to it. I've left it out of the attached set.
[1]
https://www.postgresql.org/message-id/CAD21AoBZ3t%2BfRtVamQTA%2BwBJaapFUY1dfP08-rxsQ%2BfouPvgKg%40mail.gmail.com
--
John Naylor
EDB: h
On Thu, Apr 27, 2023 at 12:58 AM Peter Geoghegan wrote:
>
> On Wed, Apr 26, 2023 at 12:16 AM John Naylor
> wrote:
> > Now is a great time to revise this section, in my view. (I myself am
about ready to get back to testing and writing for the task of removing
that "obnoxious
On Sun, Apr 30, 2023 at 4:15 AM Peter Geoghegan wrote:
>
> On Sat, Apr 29, 2023 at 1:09 AM John Naylor
> wrote:
> > I made some small changes and wrote a suitably comprehensive commit
message. I separated the possible uses for single-user mode into a separate
paragraph in the
in is itself titled "Freezing to manage the
transaction ID space".
- "The maximum “distance” that the system can tolerate..."
-> The next sentence goes on to show the "age" function, so using
different terms is a bit strange. Mixing the established age term with an
in-quotes "distance" could perhaps be done once in a definition, but then
all uses should stick to age.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, May 1, 2023 at 2:30 AM Peter Geoghegan wrote:
>
> On Sat, Apr 29, 2023 at 7:30 PM John Naylor
> wrote:
> > How about
> >
> > -HINT: To avoid a database shutdown, [...]
> > +HINT: To prevent XID exhaustion, [...]
> >
> > ...and "MXID
ping that I don't get too much push
back on this, because it's already very difficult work."
Here's some advice on how to avoid pushback:
1. Insist that all terms can only be interpreted in the most pig-headedly
literal sense possible.
2. Use that premise to pretend basic
On Tue, May 2, 2023 at 9:55 AM Peter Geoghegan wrote:
>
> On Mon, May 1, 2023 at 5:34 AM John Naylor
wrote:
> > 0003 is now a quick-and-dirty attempt at that, only in the docs. The
MXID part is mostly copy-pasted from the XID part, just to get something
together. I'd like t
holding you back, and then try to move the
> goalposts in their work"
I went to go find the phrase that I thought I was reacted to, and ...
nothing. I am also baffled. My comment was inexcusable.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, May 4, 2023 at 12:59 AM Peter Geoghegan wrote:
> I'd quite like to drop this topic, and get on with the work at hand.
I'd be grateful, and the other points you made are, of course, valid.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Apr 7, 2023 at 4:55 PM John Naylor
wrote:
> - Fixed-size PagetableEntry's are pretty large, but the tid compression
scheme used in this thread (in addition to being complex) is not a great
fit for tidbitmap because it makes it more difficult to track per-block
metadata (see a
Attached is v9, which is mostly editing the steps for restoring normal
operation, which are in 0003 now but will be squashed into 0002. Comments
to polish the wording welcome.
--
John Naylor
EDB: http://www.enterprisedb.com
From 0e9d6ea72216b196d37de4629736c0cf34e7cd5c Mon Sep 17 00:00:00 2001
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 ou
On Wed, Mar 16, 2022 at 4:48 AM Peter Geoghegan wrote:
>
> On Wed, Feb 16, 2022 at 12:43 AM John Naylor
> wrote:
> > I'll put some effort in finding any way that it might not be robust.
> > After that, changing the message and docs is trivial.
>
> It would be grea
that will
have to wait for a bit of analysis and retesting. (My earlier tests
were done in a separate module.)
The rest in this series that I looked at closely were either
refactoring or could use some minor tweaks so likely v16 material.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Apr 1, 2022 at 4:43 AM Thomas Munro wrote:
>
> On Thu, Mar 31, 2022 at 11:09 PM John Naylor
> wrote:
> > In a couple days I'm going to commit the v3 patch "accelerate tuple
> > sorting for common types" as-is after giving it one more look, barring
clause. I'll go through
the failures and see how much can be cleaned up as a preparatory
refactoring.
--
John Naylor
EDB: http://www.enterprisedb.com
Uninitialised value was created by a stack allocation
==1940791==at 0x74224E: tuplesort_putheaptuple (tuplesort.c:1800)
--
John Naylor
EDB: http://www.enterprisedb.com
e=undefined,alignment" ...
--
John Naylor
EDB: http://www.enterprisedb.com
On Sun, Apr 3, 2022 at 11:05 AM Thomas Munro wrote:
>
> Hi,
>
> Independently of a problem with a recent commit, it seems that
> $SUBJECT in all releases (well, I only tested as far back as 11).
I can confirm the problem on v10 as well.
--
John Naylor
EDB: http://www.enterprisedb.com
that time, is that good? Should I try to do it earlier,
> before we technically hit 8am? Should I do it the night before, last
> thing before I go to bed on Thursday? Do you care whether your commit
> or mine goes in first?
For these two patches, I'd say a day or two after feature freeze is a
reasonable goal.
--
John Naylor
EDB: http://www.enterprisedb.com
On Wed, Apr 6, 2022 at 10:00 AM Andres Freund wrote:
> - while working on the above point, I noticed that hash_bytes() showed up
> noticeably in profiles, so I replaced it with a fixed-width function
I'm curious about this -- could you direct me to which patch introduces this?
--
ycle.
--
John Naylor
EDB: http://www.enterprisedb.com
From 74b934bc5ed8f6733c064c0ef832e1aa9949f216 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Wed, 6 Apr 2022 16:38:28 +0700
Subject: [PATCH v5] Raise qsort insertion sort threshold
Our qsort algorithm is from NetBSD and is described in
about finding
> a way to skip the retest of column 1 in the tiebreak comparator.
> Perhaps you'd just install a different comparetup function, eg
> comparetup_index_btree_tail (which would sharing code), so no need to
> multiply specialisations for that.
If we need to add thes
Thomas and David's patches
restore performance for those.
More broadly than the regression, Thomas' is very often the fastest of
all, at the cost of more binary size. David's is occasionally slower
than v15 or v15 with revert, but much of that is a slight difference
and
acuum on a table,
will echo what they think they heard: "okay, so run a full vacuum". I
would prefer these misunderstandings to get a big fat syntax error if
they are carried out.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Apr 14, 2022 at 1:46 PM David Rowley wrote:
>
> On Wed, 13 Apr 2022 at 23:19, John Naylor
> wrote:
> > More broadly than the regression, Thomas' is very often the fastest of
> > all, at the cost of more binary size. David's is occasionally slower
>
ted keys, since
* tie-breaker comparisons may be required. Typically, the optimization
* is only of value to pass-by-value types anyway, whereas abbreviated
* keys are typically only of value to pass-by-reference types.
*/
I can take a stab at this, unless you had something else in mind.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Apr 18, 2022 at 6:54 PM 汪洋 wrote:
>
> subscribe pgsql-hackers
Hi, this mailing list is not managed by subject line. To subscribe, please visit
https://lists.postgresql.org/
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Apr 19, 2022 at 12:30 PM David Rowley wrote:
>
> Thanks for looking at this.
>
> On Tue, 19 Apr 2022 at 02:11, John Naylor
> wrote:
> > IIUC, this function is called by tuplesort_begin_common, which in turn
> > is called by tuplesort_begin_{heap, indexe
it
was a bit less noisy".
--
John Naylor
EDB: http://www.enterprisedb.com
I intend to commit David's v2 fix next week, unless there are
objections, or unless he beats me to it.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Apr 22, 2022 at 11:13 AM David Rowley wrote:
>
> On Thu, 21 Apr 2022 at 19:09, John Naylor
> wrote:
> > I intend to commit David's v2 fix next week, unless there are
> > objections, or unless he beats me to it.
>
> I wasn't sure if you wanted
ch will cause a
serious loss of performance in the resulting scanner. If you give the
flag twice, you will also get comments regarding features that lead to
minor performance losses."
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Apr 28, 2022 at 7:27 AM Euler Taveira wrote:
>
> Hi,
>
> While reading worker.c, I noticed that the referred SQL command was wrong.
> ALTER SUBSCRIPTION ... REFRESH PUBLICATION instead of ALTER TABLE ... REFRESH
> PUBLICATION. Trivial fix attached.
Pushed, thanks!
On Tue, Oct 17, 2023 at 9:39 PM Robert Haas wrote:
>
> Cool. Seems we are all in agreement, so committed these. Thanks!
Thank you for getting this across the finish line!
On Fri, Oct 13, 2023 at 10:07 AM Nathan Bossart
wrote:
>
> On Thu, Sep 14, 2023 at 04:28:26PM +0800, Junwang Zhao wrote:
> > Add a v2 with some change to fix warnings about unused-parameter.
> >
> > I will add this to Commit Fest.
>
> This looks reasonable to me. I've marked the commitfest entry
On Wed, Oct 25, 2023 at 12:21 PM Tom Lane wrote:
>
> John Naylor writes:
> > I'd prefer just adding "Assert(hentry->event == oldn);" and declaring
> > hentry PG_USED_FOR_ASSERTS_ONLY.
>
> I'm not aware of any other places where we have Asserts che
I wrote:
> Seems fine at a glance, thanks. I will build on this to implement
> variable-length values. I have already finished one prerequisite which is:
> public APIs passing pointers to values.
Since my publishing schedule has not kept up, I'm just going to share
something similar to what I m
I didn't see any recent mentions in the archives, so I'll volunteer to
be CF manager for 2023-11.
On Thu, Nov 2, 2023 at 4:35 PM Daniel Gustafsson wrote:
>
> > On 1 Nov 2023, at 07:33, John Naylor wrote:
> >
> > I didn't see any recent mentions in the archives, so I'll volunteer to
> > be CF manager for 2023-11.
>
> You probably need some extra adm
sis where I think a patch has some
momentum and needs a little push.
If you have submitted a patch this cycle and have not yet reviewed a
patch, we encourage you to sign up to do so. If you actively
reviewing, we are grateful! We perennially have plenty of code, but a
shortage of good review.
--
John Naylor
On Wed, Nov 1, 2023 at 9:18 AM Chapman Flack wrote:
> So, it would not have been my choice to assign RfC status before getting to a
> resolution on that.
It's up to the reviewer (here Chapman), not the author, to decide
whether to set it to RfC. I've set the status to "needs review".
On Sat, Oct 28, 2023 at 4:15 AM Jeff Davis wrote:
>
> I plan to commit something like v3 early next week unless someone else
> has additional comments or I missed a concern.
Hi Jeff, is the CF entry titled "Unicode character general category
functions" ready to be marked committed?
lel CREATE INDEX for BRIN indexes
Direct SSL Connections
BRIN - SK_SEARCHARRAY and scan key preprocessing
ltree hash functions
pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH
--
John Naylor
e in back branches. Consistency would preferred all else
being equal, but then again nothing is wrong with the existing links.
In any case, no one has come out in favor of the patch, so it seems
like it should be rejected unless that changes.
--
John Naylor
ave been productive to
resurrect it to the CF based on "someone plans to work on it soon".
I'm re-returning it with feedback.
Some time ago, there was a proposal to create a new category "lack of
interest", but that also seems to have gone nowhere because of...lack
of interest.
--
John Naylor
On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart wrote:
> Separately, I'm wondering whether we should consider using CFLAGS_VECTORIZE
> on the whole tree. Commit fdea253 seems to be responsible for introducing
> this targeted autovectorization strategy, and AFAICT this was just done to
> minimize th
urned with Feedback: 4. Rejected: 1.
Total: 347.
This seems in line with September, i.e. not a whole lot of change, but
plenty of discussion in various threads. We also had activity for a
minor release recently.
--
John Naylor
On Fri, Nov 17, 2023 at 5:54 AM Nathan Bossart wrote:
>
> It looks like is_valid_ascii() was originally added to pg_wchar.h so that
> it could easily be used elsewhere [0] [1], but that doesn't seem to have
> happened yet.
>
> Would moving this definition to a separate header file be a viable opti
On Sat, Nov 18, 2023 at 4:04 AM Alena Rybakina wrote:
>
> All diff files have already been added to
> v21-0002-Introduce-indexes-for-RestrictInfo patch.
Unfortunately, the patch tester is too smart for its own good, and
will try to apply .diff files as well. Since
bug_related_to_atomic_function.
On Wed, Nov 8, 2023 at 2:44 PM Xiang Gao wrote:
> * function. We could instead adopt the behavior of Arm's vmaxvq_u32(), i.e.
> * check each 32-bit element, but that would require an additional mask
> * operation on x86.
> */
> But I still don't understand why the vmaxvq_u32 intrinsic is not
On Tue, Oct 24, 2023 at 3:42 AM Nathan Bossart wrote:
>
> On Sun, Oct 22, 2023 at 12:07:59PM -0700, Andres Freund wrote:
> > Medium term, I think we need an approximate xid->"time of assignment"
> > mapping that's continually maintained on the primary. One of the things
> > that'd show us to do
On Tue, Nov 21, 2023 at 6:49 AM Andres Freund wrote:
>
> On 2023-11-20 16:34:47 +0700, John Naylor wrote:
> > Sounds like a TODO?
>
> WFM. I don't personally use or update TODO, as I have my doubts about its
> usefulness or state of maintenance. But please feel free to
On Mon, Nov 20, 2023 at 5:54 AM Jeff Davis wrote:
>
> Attached are a bunch of tiny patches and some perf numbers based on
> simple test described here:
>
> https://www.postgresql.org/message-id/04c8592dbd694e4114a3ed87139a7a04e4363030.camel%40j-davis.com
I tried taking I/O out, like this, thinkin
On Wed, Nov 22, 2023 at 12:00 AM Jeff Davis wrote:
>
> On Tue, 2023-11-21 at 16:42 +0700, John Naylor wrote:
> > The strlen call required for hashbytes() is not free.
>
> Should we have a hash_string() that's like hash_bytes() but checks for
> the NUL terminator it
On Thu, Nov 9, 2023 at 5:07 PM Amit Kapila wrote:
>
> On Wed, Nov 8, 2023 at 11:05 PM vignesh C wrote:
> >
> > On Wed, 8 Nov 2023 at 08:43, vignesh C wrote:
> >
> > Here is a small improvisation where num_slots need not be initialized
> > as it will be used only after assigning the result now. T
On Wed, Sep 27, 2023 at 11:42 PM Heikki Linnakangas wrote:
>
> Looks good to me too at a quick glance. There's this one "XXX free"
> comment though:
>
> > for (int i = 1; i < old_nbatch; ++i)
> > {
> > ParallelHashJoinBatch *shared =
> > NthParallelHashJoinB
On Tue, Oct 10, 2023 at 10:00 AM Andres Freund wrote:
>
> Hi,
>
> On 2023-10-01 14:53:23 -0400, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Is this patch still being worked on?
> >
> > I thought Andres simply hadn't gotten back to it yet.
> > It still seems like a worthwhile improvement.
>
On Mon, Sep 25, 2023 at 2:55 PM Daniel Gustafsson wrote:
>
> Fixed, along with commit message wordsmithing in the attached. Unless
> objected
> to I'll go ahead with this version.
+1
ck: 4. Withdrawn: 13. Rejected: 1.
Total: 347.
The pace seems to have picked up a bit, based on number of commits.
--
John Naylor
On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart wrote:
>
> Presently, we ask compilers to autovectorize checksum.c and numeric.c. The
> page checksum code actually lives in checksum_impl.h, and checksum.c just
> includes it. But checksum_impl.h is also used in pg_upgrade/file.c and
> pg_checksums.
On Wed, Nov 15, 2023 at 2:17 PM wrote:
>
> We can check the number of updated rows from execute plan,
> I think there is no need to return the command tag
> when EXPLAIN(ANALYZE) is executed by default.
Given that several people have voiced an opinion against this patch,
I'm marking it rejected.
ould also try to improve the hash function's collision behavior by
collecting the bytes on a uint64 and calling our new murmur64 before
returning the lower half, but that's speculative.
From 1a516bb341afb72680470897d75c1d23f75fb37e Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Wed, 22
On Thu, Nov 23, 2023 at 5:34 AM Andres Freund wrote:
> It's worth noting that the limited range of the input values means that
> there's a lot of bias toward some bits being set ('a' to 'z' all start with
> 0b011).
We can take advantage of the limited range with a single additional
instruction:
On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart wrote:
>
> On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
> > On Wed, 22 Nov 2023 at 11:44, John Naylor wrote:
> >> Poking in those files a bit, I also see references to building with
> >> SSE 4.1. Maybe t
On Thu, Nov 23, 2023 at 4:29 PM Xiang Gao wrote:
>
> Thank you for your detailed explanation.
> Can I do some testing and submit this patch?
Please do, thanks.
On Thu, Nov 23, 2023 at 11:51 PM Nathan Bossart
wrote:
>
> On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
> > On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart
> > wrote:
> >> One half-formed idea I have is to introduce some sort of ./configure flag
>
On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart wrote:
>
> On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
> > For reference, executing the page checksum 10M times on a AMD 3900X CPU:
> >
> > clang-14 -O2 4.292s (17.8 GiB/s)
> > clang-14 -O2 -msse4.12.859s (26.7
On Mon, Nov 27, 2023 at 8:57 PM Andrew Dunstan wrote:
> Interesting. But inferring a speed effect from such changes is
> difficult. I don't have a good idea about measuring parser speed, but a
> tool to do that would be useful. Amit has made a start on such
> measurements, but it's only a start. I
On Tue, Nov 28, 2023 at 7:51 AM Andres Freund wrote:
>
> Hi,
>
> On 2023-11-25 14:09:14 +0700, John Naylor wrote:
> > * Note: I have seen the threads with the idea of compiling multiple
> > entire binaries, and switching at postmaster start. I think it's a
>
remental interface, with implementations
for dynahash (getting rid of strlen) and guc hash.
[1] https://code.google.com/archive/p/fast-hash/
[2] https://github.com/jonmaiga/mx3
From c2b799dd2418fb68fcfc6ccf006a50f74c9072fe Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Wed, 29 Nov 2023 16:28:58 +0
On Wed, Nov 29, 2023 at 9:59 PM Heikki Linnakangas wrote:
>
> I didn't understand what you meant by the above. Did you wack around
> fast-hash, or who did?
I turned it into an init/accum/final style (shouldn't affect the
result), and took out the input length from the calculation (will
affect the
On Thu, Sep 14, 2023 at 3:28 PM Junwang Zhao wrote:
>
> Add a v2 with some change to fix warnings about unused-parameter.
>
> I will add this to Commit Fest.
Pushed v2 after removing asserts, as well as the unnecessary cast that
I complained about earlier.
Some advice: I was added as a reviewer
On Wed, Nov 8, 2023 at 2:02 PM John Naylor wrote:
> My 2 cents: Comment typos are visible to readers, so more annoying
> when seen in isolation, and less likely to have surroundings that
> could change in back branches. Consistency would preferred all else
> being equal, but then a
On Wed, Mar 22, 2023 at 9:06 PM Jonathan S. Katz wrote:
>
> Maybe I'm not conveying the problem this is solving -- I'm happy to go
> one more round trying to make it clearer -- but if this is not clear,
> it'd be good to at develop an alternative approach to this before
> withdrawing the patch.
T
ht I remembered discussion on a "bulk move" button,
but if it's there, I can't find it...
--
John Naylor
On Wed, Nov 29, 2023 at 8:31 PM John Naylor wrote:
>
> Attached is a rough start with Andres's earlier ideas, to get
> something concrete out there.
While looking at the assembly out of curiosity, I found a couple bugs
in the split API that I've fixed locally.
I think
On Mon, Dec 4, 2023 at 4:16 AM Jeff Davis wrote:
> I'm trying to follow the distinctions you're making between dynahash
> and simplehash -- are you saying it's easier to do incremental hashing
> with dynahash, and if so, why?
That's a good thing to clear up. This thread has taken simplehash as a
On Thu, Nov 30, 2023 at 4:37 PM Alexander Korotkov wrote:
>
> On Thu, Nov 30, 2023 at 10:29 AM Pavel Borisov wrote:
> > Agree. The fix is attached.
>
> What an oversight.
> Thank you, pushed!
With that, is there any more work pending, or can we close the CF entry?
On Mon, Nov 27, 2023 at 1:45 PM Masahiko Sawada wrote:
> Since the variable-length values support is a big deal and would be
> related to API design I'd like to discuss the API design first.
Thanks for the fine summary of the issues here.
[Swapping this back in my head]
> RT_VALUE_TYPE
> RT_GE
On Thu, Sep 28, 2023 at 12:22 AM Alexander Korotkov
wrote:
> The one thing triggering my perfectionism is that the patch does two
> syscache lookups instead of one.
For an admin function used interactively, I'm not sure why that
matters? Or do you see another use case?
On Mon, Dec 4, 2023 at 3:12 PM Pavel Borisov wrote:
> I think this is complete and could be closed.
Done.
with very many patches, but after
moving November over, there are plenty that have no reviewer of
record.
--
John Naylor
On Mon, Dec 4, 2023 at 5:03 PM Krishnakumar R wrote:
>
> Hi,
>
> As per discussion in [1] splitting the patch. Part1 moves replacement
> logic in initdb of NAMEDATALEN, FLOAT8PASSBYVAL, SIZEOF_VOID_P,
> ALIGNOF_POINTER to compile time via genbki.pl.
Hi Krishnakumar,
Note this comment in genbki.
On Tue, Dec 5, 2023 at 7:55 AM Jeff Davis wrote:
>
> On Tue, 2023-11-21 at 09:24 -0500, Robert Haas wrote:
> > As to the second, could we somehow come
> > up with an API for guc.c where you can ask for an opaque handle that
> > will later allow you to do a fast-SET of a GUC?
>
> Yes, attached. Tha
On Tue, Dec 5, 2023 at 1:57 AM Jeff Davis wrote:
>
> On Mon, 2023-12-04 at 12:12 +0700, John Naylor wrote:
> There's already a patch to use simplehash, and the API is a bit
> cleaner, and there's a minor performance improvement. It seems fairly
> non-controversial -- s
On Wed, Dec 6, 2023 at 4:34 AM Masahiko Sawada wrote:
>
> On Mon, Dec 4, 2023 at 5:21 PM John Naylor wrote:
> > > Given variable-length value support, RT_GET() would have to do
> > > repalloc() if the existing value size is not big enough for the new
> > > value
On Wed, Dec 6, 2023 at 11:48 PM Jeff Davis wrote:
>
> On Wed, 2023-12-06 at 07:39 +0700, John Naylor wrote:
> > "git grep cstring_hash" found nothing, so not sure what you're
> > asking.
>
> Sorry, I meant string_hash(). Your v5-0002 changes the way hashi
On Mon, Nov 27, 2023 at 1:45 PM Masahiko Sawada wrote:
>
> On Sat, Oct 28, 2023 at 5:56 PM John Naylor wrote:
> bool
> RT_SET(RT_RADIX_TREE *tree, uint64 key, RT_VALUE_TYPE *value_p);
> or for variable-length value support,
> RT_SET(RT_RADIX_TREE *tree, uint64 key, RT_V
On Fri, Dec 8, 2023 at 8:57 AM Masahiko Sawada wrote:
> It's still unclear to me why the value doesn't need to contain the size.
>
> If I understand you correctly, in RT_GET(), the tree allocs a new
> memory and updates the slot where the value is embedded with the
> pointer to the allocated memo
On Fri, Dec 8, 2023 at 10:32 AM Nathan Bossart wrote:
>
> On Fri, Dec 08, 2023 at 04:11:52PM +1300, David Rowley wrote:
> > + seplen = use_line_feeds ? sizeof(",\n ") - 1 : sizeof(",") - 1;
> >
> > Most modern compilers will be fine with just:
> >
> > seplen = strlen(sep);
> >
> > I had to go back
On Fri, Dec 8, 2023 at 3:06 PM Masahiko Sawada wrote:
>
> BTW Given that the actual value size can be calculated only by the
> caller, how does the tree know if the value is embedded or not? It's
> probably related to how to store combined pointer/value slots.
Right, this is future work. At first
On Sat, Dec 9, 2023 at 3:32 AM Jeff Davis wrote:
>
> On Wed, 2023-11-29 at 20:31 +0700, John Naylor wrote:
> > Attached is a rough start with Andres's earlier ideas, to get
> > something concrete out there.
>
> The implementation of string hash in 0004 forgot to inc
501 - 600 of 1520 matches
Mail list logo
