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
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 Mon, Dec 4, 2023 at 3:12 PM Pavel Borisov wrote:
> I think this is complete and could be closed.
Done.
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 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
>
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
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
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
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.
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 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 hashing
&g
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
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
On Wed, Jan 31, 2024 at 12:50 PM Masahiko Sawada wrote:
> I've attached the new patch set (v56). I've squashed previous updates
> and addressed review comments on v55 in separate patches. Here are the
> update summary:
>
> 0004: fix compiler warning caught by ci test.
> 0005-0008: address review
badd8c0f1ade79c88c27b455 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Tue, 30 Jan 2024 16:14:57 +0700
Subject: [PATCH v17 2/2] Shorten dependency chain for computing hash mask
---
src/include/common/hashfn_unstable.h | 30
1 file changed, 13 insertions(+), 17 d
ed to explain usage, so I plan to hold on to
this for later. Let me know what you think.
[1] Examples of both in
https://www.boost.org/doc/libs/1_84_0/boost/container_hash/detail/hash_mix.hpp
From ad25c43c264c5857bf41cbf056ac7d4ab0995b40 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Sun, 21 Ja
On Fri, Jan 19, 2024 at 9:03 PM Peter Eisentraut wrote:
>
> The DECLARE_* macros map to actual BKI commands ("declare toast",
> "declare index"). So I wanted to use a different verb to distinguish
> "generate code for this" from those BKI commands.
That makes sense to me.
On Mon, Jan 22, 2024 at 2:24 PM Masahiko Sawada wrote:
>
> For the next version patch, I'll work on this idea and try to clean up
> locking stuff both in tidstore and radix tree. Or if you're already
> working on some of them, please let me know. I'll review it.
Okay go ahead, sounds good. I
On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> And 397->320ms
> for something as core as this, is imo worth considering on its own.
Hi Andres, this interesting work seems to have fallen off the radar --
are you still planning to move forward with this for v17?
I wrote:
> On Thu, Jan 18, 2024 at 8:31 AM Masahiko Sawada wrote:
> > During trying this idea, I realized that there is a visibility problem
> > in the radix tree template
>
> If it's broken even without the embedding I'll look into this (I don't
> know if this configuration has ever been
On Mon, Jan 22, 2024 at 10:28 AM Masahiko Sawada wrote:
>
> On further thought, as you pointed out before, "num_tids" should not
> be in tidstore in terms of integration with tidbitmap.c, because
> tidbitmap.c has "lossy pages". With lossy pages, "num_tids" is no
> longer accurate and useful.
On Mon, Nov 27, 2023 at 9:06 PM Alvaro Herrera wrote:
> At this point one thing that IMO we cannot afford to do, is stop feature
> progress work on the name of parser speed. I mean, parser speed is
> important, and we need to be mindful that what we add is reasonable.
> But at some point we'll
& ((~0ULL) >> (64 - BITS_PER_BYTE*remainder));
+#endif
+ fasthash_combine(hs);
+
+ str += remainder;
+ }
return str - start;
}
--
2.43.0
From a1e1648f3f3a25001c62fffe7dcd422273619e3e Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Tue, 30 Jan 2024 16:14:57 +0700
Subject: [PATCH v16 2/2] Shorten
On Tue, Jan 30, 2024 at 7:56 AM Masahiko Sawada wrote:
>
> On Mon, Jan 29, 2024 at 8:48 PM John Naylor wrote:
> > I meant the macro could probably be
> >
> > Max(SLAB_DEFAULT_BLOCK_SIZE, (size) * N)
> >
> > (Right now N=32). I also realize I didn't answer y
On Mon, Jan 29, 2024 at 2:29 PM Masahiko Sawada wrote:
> > > +/*
> > > + * Calculate the slab blocksize so that we can allocate at least 32
> > > chunks
> > > + * from the block.
> > > + */
> > > +#define RT_SLAB_BLOCK_SIZE(size) \
> > > + Max((SLAB_DEFAULT_BLOCK_SIZE / (size)) * (size), (size)
pass the length (or
> a dummy macro) up front -- with a compile-time fixed length, it can't
> possibly break a tie, so it's just noise.
This was a wart, so pushed removing initial length from the incremental API.
On Mon, Jan 22, 2024 at 11:16 AM Jeff Davis wrote:
>
> On Mon, 2024-01-22
On Sat, Jan 20, 2024 at 7:13 AM Jeff Davis wrote:
>
> On Fri, 2024-01-19 at 13:38 -0800, Jeff Davis wrote:
> > One post-commit question on 0aba255440: why do
> > haszero64(pg_bswap64(chunk)) rather than just haszero64(chunk)? How
> > does byteswapping affect whether a zero byte exists or not?
>
>
On Fri, Jan 19, 2024 at 11:54 PM Heikki Linnakangas wrote:
> Thanks! I started to look at how to use this, and I have some questions.
> I'd like to replace this murmurhash ussage in resowner.c with this:
>
> > /*
> >* Most resource kinds store a pointer in 'value', and pointers are
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
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 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
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
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
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 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 add
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,
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
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 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 =
> >
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
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
>
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.
. Withdrawn: 13. Rejected: 1.
Total: 347.
The pace seems to have picked up a bit, based on number of commits.
--
John Naylor
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 itse
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.
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.
ollision 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 Nov 2023 17:28:41 +0700
Subject: [PATCH v4 1/3] Add finalize
On Tue, Jan 16, 2024 at 1:18 PM Masahiko Sawada wrote:
> Just changing "items" to be the local tidstore struct could make the
> code tricky a bit, since max_bytes and num_items are on the shared
> memory while "items" is a local pointer to the shared tidstore.
Thanks for trying it this way! I
On Wed, Jan 17, 2024 at 8:39 AM Masahiko Sawada wrote:
>
> On Wed, Jan 17, 2024 at 9:20 AM John Naylor wrote:
> >
> > On Tue, Jan 16, 2024 at 1:18 PM Masahiko Sawada
> > wrote:
> > > Just changing "items" to be the local tidstore struct could make t
I wrote:
> > Hmm, I wonder if that's a side-effect of the "create" functions doing
> > their own allocations and returning a pointer. Would it be less tricky
> > if the structs were declared where we need them and passed to "init"
> > functions?
If this is a possibility, I thought I'd first send
to have another look.
After this first step is out of the way, we can look into using this
more widely, including dynahash and the GUC hash.
From cff2bfda6a3067936ef17162a2db2609185afb24 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Tue, 16 Jan 2024 16:32:48 +0700
Subject: [PATCH v14 2/2] Add
I wrote:
> Secondly, I thought about my recent work to skip checking if we first
> need to create a root node, and that has a harmless (for vacuum at
> least) but slightly untidy behavior: When RT_SET is first called, and
> the key is bigger than 255, new nodes will go on top of the root node.
>
I'm looking at RT_FREE_RECURSE again (only used for DSA memory), and
I'm not convinced it's freeing all the memory. It's been many months
since we discussed this last, but IIRC we cannot just tell DSA to free
all its segments, right? Is there currently anything preventing us
from destroying the
On Fri, Mar 1, 2024 at 3:01 PM Masahiko Sawada wrote:
>
> On Thu, Feb 29, 2024 at 8:43 PM John Naylor wrote:
> > + ts->rt_context = AllocSetContextCreate(CurrentMemoryContext,
> > +"tidstore storage",
> >
> > "tidstore storage" sounds
On Mon, Mar 4, 2024 at 1:05 PM Masahiko Sawada wrote:
>
> On Sun, Mar 3, 2024 at 2:43 PM John Naylor wrote:
> > Right, I should have said "reset". Resetting a context will delete
> > it's children as well, and seems like it should work to reset the tree
> >
On Tue, Feb 20, 2024 at 1:59 PM Masahiko Sawada wrote:
> - v63-0008 patch fixes a bug in tidstore.
- page->nwords = wordnum + 1;
- Assert(page->nwords = WORDS_PER_PAGE(offsets[num_offsets - 1]));
+ page->nwords = wordnum;
+ Assert(page->nwords == WORDS_PER_PAGE(offsets[num_offsets - 1]));
On Tue, Mar 5, 2024 at 8:27 AM Masahiko Sawada wrote:
>
> On Mon, Mar 4, 2024 at 8:48 PM John Naylor wrote:
> >
> > On Mon, Mar 4, 2024 at 1:05 PM Masahiko Sawada
> > wrote:
> > > Resetting the tree->context seems to work. But I think we should note
> &
On Tue, Jan 30, 2024 at 5:04 PM John Naylor wrote:
>
> On Tue, Jan 30, 2024 at 4:13 AM Ants Aasma wrote:
> > But given that we know the data length and we have it in a register
> > already, it's easy enough to just mask out data past the end with a
> > shift. See patc
Actually, I forgot -- I had one more question: Masahiko, is there a
reason for this extra local variable, which uses the base type, rather
than the typedef'd parameter?
+RT_SCOPE RT_RADIX_TREE *
+RT_ATTACH(dsa_area *dsa, RT_HANDLE handle)
+{
+ RT_RADIX_TREE *tree;
+ dsa_pointer control;
+
+ tree
On Tue, Mar 5, 2024 at 11:12 PM Masahiko Sawada wrote:
>
> > I'd like to push 0001 and 0002 shortly, and then do another sweep over
> > 0003, with remaining feedback, and get that in so we get some
> > buildfarm testing before the remaining polishing work on
> > tidstore/vacuum.
>
> Sounds a
On Fri, Mar 8, 2024 at 9:53 AM John Naylor wrote:
>
> On Fri, Mar 8, 2024 at 8:09 AM Masahiko Sawada wrote:
> > Yesterday I've confirmed the something like the below fixes the
> > problem happened in Windows CI:
> >
> > --- a/src/test/modules/test_radixtree/meson.bu
On Fri, Mar 8, 2024 at 8:09 AM Masahiko Sawada wrote:
>
> Yesterday I've confirmed the something like the below fixes the
> problem happened in Windows CI:
Glad you shared before I went and did it.
> --- a/src/test/modules/test_radixtree/meson.build
> +++
On Fri, Mar 8, 2024 at 8:09 AM Masahiko Sawada wrote:
> Yesterday I've confirmed the something like the below fixes the
> problem happened in Windows CI:
>
> --- a/src/test/modules/test_radixtree/meson.build
> +++ b/src/test/modules/test_radixtree/meson.build
> @@ -12,6 +12,7 @@ endif
>
>
On Thu, Mar 7, 2024 at 11:15 PM Masahiko Sawada wrote:
>
> It looks like it requires a link with pgport_srv but I'm not sure. It
> seems that the recent commit 1f1d73a8b breaks CI, Windows - Server
> 2019, VS 2019 - Meson & ninja, too.
Unfortunately, none of the Windows animals happened to run
On Thu, Mar 7, 2024 at 1:27 PM Masahiko Sawada wrote:
>
> On Thu, Mar 7, 2024 at 3:20 PM John Naylor wrote:
> >
> > On Thu, Mar 7, 2024 at 12:59 PM John Naylor wrote:
> > > ... cause "error: redefinition of typedef 'rt_radix_tree' is a C11
> > >
On Wed, Mar 6, 2024 at 6:59 PM Masahiko Sawada wrote:
>
> > + /* Find the control object in shared memory */
> > + control = handle;
>
> I think it's mostly because of readability; it makes clear that the
> handle should be castable to dsa_pointer and it's a control object. I
> borrowed it from
On Thu, Mar 7, 2024 at 12:59 PM John Naylor wrote:
>
> On Thu, Mar 7, 2024 at 12:55 PM John Naylor wrote:
> >
> > On Wed, Mar 6, 2024 at 6:59 PM Masahiko Sawada
> > wrote:
> > >
> > > > + /* Find the control object in shared memory */
> > >
On Thu, Mar 7, 2024 at 12:55 PM John Naylor wrote:
>
> On Wed, Mar 6, 2024 at 6:59 PM Masahiko Sawada wrote:
> >
> > > + /* Find the control object in shared memory */
> > > + control = handle;
> >
> > I think it's mostly because of readability;
On Thu, Mar 7, 2024 at 2:14 PM Masahiko Sawada wrote:
>
> On Thu, Mar 7, 2024 at 4:01 PM John Naylor wrote:
> >
> > On Thu, Mar 7, 2024 at 1:27 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Mar 7, 2024 at 3:20 PM John Naylor
> > > wro
On Tue, Mar 12, 2024 at 6:41 AM David Rowley wrote:
> Thanks for trying this out. I didn't check if the performance was
> susceptible to the memory size before the reset. It certainly would
> be once the allocation crosses some critical threshold of CPU cache
> size, but probably it will also
On Mon, Mar 11, 2024 at 3:13 PM Masahiko Sawada wrote:
>
> On Mon, Mar 11, 2024 at 12:20 PM John Naylor wrote:
> >
> > On Thu, Mar 7, 2024 at 10:35 PM Masahiko Sawada
> > wrote:
> > + ts->context = CurrentMemoryContext;
> >
> > As far as I can tell
On Thu, Mar 7, 2024 at 10:35 PM Masahiko Sawada wrote:
>
> I've attached the remaining patches for CI. I've made some minor
> changes in separate patches and drafted the commit message for
> tidstore patch.
>
> While reviewing the tidstore code, I thought that it would be more
> appropriate to
On Fri, Feb 16, 2024 at 10:05 AM Masahiko Sawada wrote:
>
> On Thu, Feb 15, 2024 at 8:26 PM John Naylor wrote:
> > v61-0007: Runtime-embeddable tids -- Optional for v17, but should
> > reduce memory regressions, so should be considered. Up to 3 tids can
> > be stored
On Tue, Mar 5, 2024 at 9:42 AM David Rowley wrote:
> performance against the recently optimised aset, generation and slab
> contexts. The attached graph shows the time it took in seconds to
> allocate 1GB of memory performing a context reset after 1MB. The
> function I ran the test on is in the
On Tue, Mar 19, 2024 at 9:03 AM Nathan Bossart wrote:
>
> On Sun, Mar 17, 2024 at 09:47:33AM +0700, John Naylor wrote:
> > I haven't looked at the patches, but the graphs look good.
>
> I spent some more time on these patches. Specifically, I reordered them to
> de
On Mon, Mar 18, 2024 at 11:12 AM Masahiko Sawada wrote:
>
> On Sun, Mar 17, 2024 at 11:46 AM John Naylor wrote:
> > Random offsets is what I was thinking of (if made distinct and
> > ordered), but even there the code is fairy trivial, so I don't have a
> > strong feel
On Tue, Mar 19, 2024 at 10:24 AM Masahiko Sawada wrote:
>
> On Tue, Mar 19, 2024 at 8:35 AM John Naylor wrote:
> >
> > On Mon, Mar 18, 2024 at 11:12 AM Masahiko Sawada
> > wrote:
> > >
> > > On Sun, Mar 17, 2024 at 11:46 AM John Naylor
> &g
On Tue, Mar 19, 2024 at 10:16 AM Nathan Bossart
wrote:
>
> On Tue, Mar 19, 2024 at 10:03:36AM +0700, John Naylor wrote:
> > I took a brief look, and 0001 isn't quite what I had in mind. I can't
> > quite tell what it's doing with the additional branches and "goto
> >
On Thu, Mar 14, 2024 at 12:06 PM Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 1:29 PM John Naylor wrote:
> > Okay, here's an another idea: Change test_lookup_tids() to be more
> > general and put the validation down into C as well. First we save the
> > blocks f
ds_idx + i]);
+
+ Assert((iter->tids_idx + i) < iter->ts->max_tids);
+ Assert(ItemPointerGetBlockNumber(tid) == blkno);
+ Assert(ItemPointerGetOffsetNumber(tid) == iter->output.offsets[i]);
+ }
+
+ iter->tids_idx += iter->output.num_offsets;
+}
+#endif
--
2.44.0
From 4ed9f578
On Thu, Mar 21, 2024 at 4:03 PM Masahiko Sawada wrote:
>
> I've looked into this idea further. Overall, it looks clean and I
> don't see any problem so far in terms of integration with lazy vacuum.
> I've attached three patches for discussion and tests.
Seems okay in the big picture, it's the
On Thu, Mar 21, 2024 at 1:11 PM Masahiko Sawada wrote:
> Or we can have a new function for dsa.c to set the initial and max
> segment size (or either one) to the existing DSA area so that
> TidStoreCreate() can specify them at creation.
I didn't like this very much, because it's splitting an
On Thu, Mar 21, 2024 at 2:55 AM Nathan Bossart wrote:
>
> On Wed, Mar 20, 2024 at 09:31:16AM -0500, Nathan Bossart wrote:
> > I don't mind removing the 2-register stuff if that's what you think we
> > should do. I'm cautiously optimistic that it'd help more than the extra
> > branch prediction
On Thu, Mar 21, 2024 at 9:37 AM Masahiko Sawada wrote:
>
> On Wed, Mar 20, 2024 at 11:19 PM John Naylor wrote:
> > Are they (the blocks to be precise) really out of order? The VALUES
> > statement is ordered, but after inserting it does not output that way.
> > I wond
On Thu, Mar 14, 2024 at 7:04 PM Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 6:55 PM John Naylor wrote:
> >
> > On Thu, Mar 14, 2024 at 12:06 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Mar 14, 2024 at 1:29 PM John Naylor
> > >
On Fri, Mar 15, 2024 at 9:17 PM Masahiko Sawada wrote:
>
> On Fri, Mar 15, 2024 at 4:36 PM John Naylor wrote:
> >
> > On Thu, Mar 14, 2024 at 7:04 PM Masahiko Sawada
> > wrote:
> > > Given TidStoreSetBlockOffsets() is designed to always set (i.e.
> > &g
On Sat, Mar 16, 2024 at 2:40 AM Nathan Bossart wrote:
>
> On Fri, Mar 15, 2024 at 12:41:49PM -0500, Nathan Bossart wrote:
> > I've also attached the results of running this benchmark on my machine at
> > HEAD, after applying 0001, and after applying both 0001 and 0002. 0001
> > appears to work
On Thu, Mar 14, 2024 at 12:06 PM Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 1:29 PM John Naylor wrote:
> > Locally (not CI), we should try big inputs to make sure we can
> > actually go up to many GB -- it's easier and faster this way than
> > having vacuum
On Tue, Mar 19, 2024 at 11:30 PM Nathan Bossart
wrote:
> > Sounds similar in principle, but it looks really complicated. I don't
> > think the additional loops and branches are a good way to go, either
> > for readability or for branch prediction. My sketch has one branch for
> > which loop to
On Tue, Mar 5, 2024 at 5:30 PM John Naylor wrote:
>
> On Tue, Jan 30, 2024 at 5:04 PM John Naylor wrote:
> >
> > On Tue, Jan 30, 2024 at 4:13 AM Ants Aasma wrote:
> > > But given that we know the data length and we have it in a register
> > > already, it's ea
On Wed, Mar 20, 2024 at 8:30 PM Masahiko Sawada wrote:
> I forgot to report the results. Yes, I did some tests where I inserted
> many TIDs to make the tidstore use several GB memory. I did two cases:
>
> 1. insert 100M blocks of TIDs with an offset of 100.
> 2. insert 10M blocks of TIDs with an
On Thu, Mar 7, 2024 at 1:49 PM Masahiko Sawada wrote:
> odr-violation seems to refer to One Definition Rule (ODR). According
> to Wikipedia[1]:
>
> The One Definition Rule (ODR) is an important rule of the C++
> programming language that prescribes that classes/structs and
> non-inline functions
On Thu, Mar 7, 2024 at 1:19 PM John Naylor wrote:
>
> In addition, olingo and grassquit are showing different kinds of
> "AddressSanitizer: odr-violation" errors, which I'm not sure what to
> make of -- example:
This might be relevant:
$ git grep 'link_with: pgport
On Thu, Mar 7, 2024 at 4:47 PM Masahiko Sawada wrote:
>
> On Thu, Mar 7, 2024 at 6:37 PM John Naylor wrote:
> > $ git grep 'link_with: pgport_srv'
> > src/test/modules/test_radixtree/meson.build: link_with: pgport_srv,
> >
> > No other test module uses this d
On Tue, Mar 5, 2024 at 11:12 PM Masahiko Sawada wrote:
>
> On Tue, Mar 5, 2024 at 6:41 PM John Naylor wrote:
> > Done in v66-0009. I'd be curious to hear any feedback. I like the
> > aspect that the random numbers come from a different seed every time
> > the test runs
On Wed, Mar 6, 2024 at 3:02 PM Masahiko Sawada wrote:
>
> On Wed, Mar 6, 2024 at 4:41 PM Andres Freund wrote:
> > A few ARM buildfarm animals are complaining:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=parula=2024-03-06%2007%3A34%3A02
> >
On Wed, Mar 6, 2024 at 3:06 PM John Naylor wrote:
>
> (Hmm, I thought we had run this code on Arm already...)
CI MacOS uses Clang on aarch64, which has been working fine. The
failing animals are on gcc 7.3...
1201 - 1300 of 1334 matches
Mail list logo
