On Mon, May 20, 2024 at 8:41 PM Masahiko Sawada wrote:
>
> On Mon, May 20, 2024 at 8:47 PM Jonathan S. Katz wrote:
> >
> > On 5/20/24 2:58 AM, John Naylor wrote:
> > > Hi Jon,
> > >
> > > Regarding vacuum "has shown up to a 6x improvement in ove
Hi Jon,
Regarding vacuum "has shown up to a 6x improvement in overall time to
complete its work" -- I believe I've seen reported numbers close to
that only 1) when measuring the index phase in isolation or maybe 2)
the entire vacuum of unlogged tables with one, perfectly-correlated
index (testing
0e7ff51f4a..612eb100a7 100644
--- a/doc/src/sgml/release-17.sgml
+++ b/doc/src/sgml/release-17.sgml
@@ -492,23 +492,23 @@ Allow BRIN indexes to be created using parallel workers (Tomas Vondra, Matthias
-Allow vacuum to more efficiently remove and freeze tuples (Masahiko Sawada, John Naylor
On Mon, May 20, 2024 at 11:59 AM Masahiko Sawada wrote:
>
> On Fri, May 17, 2024 at 5:55 AM Andres Freund wrote:
> > I think we should consider lowering the minimum setting of
> > maintenance_work_mem to the minimum of work_mem.
>
> +1 for lowering the minimum value of maintenance_work_mem.
On Thu, Apr 25, 2024 at 8:36 AM Masahiko Sawada wrote:
>
> On Mon, Apr 15, 2024 at 6:12 PM John Naylor wrote:
> > - RT_KEY_GET_SHIFT is not covered for key=0:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L803
>
On Wed, Apr 17, 2024 at 7:21 AM John Naylor wrote:
>
> On Mon, Apr 15, 2024 at 9:20 PM Marina Polyakova
> wrote:
> > Everything seems to work with this patch, thank you!
>
> Glad to hear it -- I'll push next week when I get back from vacation,
> unless there are obj
On Fri, Apr 26, 2024 at 6:54 PM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
On Thu, Apr 25, 2024 at 9:50 AM Masahiko Sawada wrote:
>
> > I saw a SIGSEGV there when using tidstore to write a fix for something else.
> > Patch attached.
>
> Great find, thank you for the patch!
+1
(This occurred to me a few days ago, but I was far from my computer.)
With the purge
On Mon, Apr 15, 2024 at 9:20 PM Marina Polyakova
wrote:
>
> On 2024-04-13 08:40, John Naylor wrote:
> > so that they build fine on PG16 as well. The problem is, not all the
> > required headers are generated when invoking `make headerscheck`. The
> > attached patch bring
I took a look at the coverage report from [1] and it seems pretty
good, but there are a couple more tests we could do.
- RT_KEY_GET_SHIFT is not covered for key=0:
https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L803
That should be fairly simple to
On Fri, Apr 12, 2024 at 11:51 PM Marina Polyakova
wrote:
>
> Hello, hackers!
>
> When running cpluspluscheck/headerscheck on REL_16_STABLE [1] I found
> that everything was ok only if it was preceded by a build and make
> maintainer-clean was not used:
I can reproduce this.
> In the other
On Tue, Apr 9, 2024 at 2:47 AM Robert Haas wrote:
>
> - I'm slightly worried about the TID store work (ee1b30f12, 30e144287,
> 667e65aac35), perhaps for no reason. Actually, the results seem really
> impressive,
First, thanks for the complement. I actually suspect if we had this
years ago, it
On Mon, Apr 8, 2024 at 7:26 PM John Naylor wrote:
>
> I pushed both of these and see that mylodon complains that anonymous
> unions are a C11 feature. I'm not actually sure that the union with
> uintptr_t is actually needed, though, since that's not accessed as
> such here. The
On Mon, Apr 8, 2024 at 7:42 PM Pavel Borisov wrote:
>
>> I pushed both of these and see that mylodon complains that anonymous
>> unions are a C11 feature. I'm not actually sure that the union with
>> uintptr_t is actually needed, though, since that's not accessed as
>> such here. The simplest
On Sun, Apr 7, 2024 at 9:08 AM John Naylor wrote:
>
> I've attached a mostly-polished update on runtime embeddable values,
> storing up to 3 offsets in the child pointer (1 on 32-bit platforms).
> As discussed, this includes a macro to cap max possible offset that
> can be store
On Mon, Apr 8, 2024 at 2:07 AM Andres Freund wrote:
>
> Looking at the code, the failure isn't suprising anymore:
> chardata[MaxBlocktableEntrySize];
> BlocktableEntry *page = (BlocktableEntry *) data;
>
> 'char' doesn't enforce any alignment, but you're storing a
On Sat, Apr 6, 2024 at 7:37 PM David Rowley wrote:
>
I'm planning on pushing these, pending a final look at 0002 and 0003
> on Sunday morning NZ time (UTC+12), likely in about 10 hours time.
+1
I haven't looked at v6, but I've tried using it in situ, and it seems
to work as well as hoped:
On Sun, Apr 7, 2024 at 9:08 AM John Naylor wrote:
> I've attached a mostly-polished update on runtime embeddable values,
> storing up to 3 offsets in the child pointer (1 on 32-bit platforms).
And...since there's a new bump context patch, I wanted to anticipate
squeezing an update
On Sun, Apr 7, 2024 at 11:49 AM Andres Freund wrote:
>
> Hi,
>
> On 2024-01-22 13:01:31 +0700, John Naylor wrote:
> > On Mon, Jul 17, 2023 at 9:58 PM Andres Freund wrote:
> > > And 397->320ms
> > > for something as core as this, is imo worth co
would be committed in two pieces as
well, since they are independently useful.
From 24bd672deb4a6fa14abfc8583b500d1cbc332032 Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Fri, 5 Apr 2024 17:04:12 +0700
Subject: [PATCH v83 1/3] store offsets in the header
---
src/backend/access/common/tids
calls for dynahash
and dshash string keys. I'm not quite sure how the comments should be
updated about string_hash being deprecated to call directly. This
patch goes further and semi-deprecates calling it at all, so these
comments seem a bit awkward now.
From 2e41e683b2fe2bc76b808e58ca2fea9067bff4e1 Mon
On Sat, Apr 6, 2024 at 3:47 AM Jeff Davis wrote:
> In hashfn_unstable.h, fasthash32() is declared as:
>
> /* like fasthash64, but returns a 32-bit hashcode */
> static inline uint64
> fasthash32(const char *k, size_t len, uint64 seed)
>
> Is the return type of uint64 a typo?
Yes it is,
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 Thu, Mar 28, 2024 at 12:37 PM Jeff Davis wrote:
>
> > v21-0003 adds a new file hashfn_unstable.c for convenience functions
> > and converts all the duplicate frontend uses of hash_string_pointer.
>
> Why not make hash_string() inline, too? I'm fine with it either way,
> I'm just curious why
th the previous array, we don't take any locks on TidStore during
parallel vacuum since writes are still only done by the leader process.
XXX: bump catalog version
Reviewed-by: John Naylor, (in an earlier version) Dilip Kumar
Discussion:
https://postgr.es/m/CAD21AoAfOZvmfR0j8VmZorZjL7RhTiQdVttNuC4W-Shdc2a-AA%40mail.gmail.com
On Thu, Mar 28, 2024 at 12:55 PM Masahiko Sawada wrote:
>
> Pushed the refactoring patch.
>
> I've attached the rebased vacuum improvement patch for cfbot. I
> mentioned in the commit message that this patch eliminates the 1GB
> limitation.
>
> I think the patch is in good shape. Do you have
0002 shortly.
From 690061ff4a54e7baef213bb16e7cc4c4f4c79dbd Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Tue, 6 Feb 2024 13:11:33 +0700
Subject: [PATCH v20 2/3] Speed up tail processing when hashing aligned C
strings
After encountering the NUL terminator, the word-at-a-time loop e
On Mon, Mar 25, 2024 at 8:07 PM Masahiko Sawada wrote:
>
> On Mon, Mar 25, 2024 at 3:25 PM John Naylor wrote:
> >
> > On Fri, Mar 22, 2024 at 12:20 PM Masahiko Sawada
> > wrote:
> > - * remaining LP_DEAD line pointers on the page in the dead_items
> > - * a
On Fri, Mar 22, 2024 at 12:20 PM Masahiko Sawada wrote:
>
> On Thu, Mar 21, 2024 at 7:48 PM John Naylor wrote:
> > v77-0001
> >
> > - dead_items = (VacDeadItems *)
> > palloc(vac_max_items_to_alloc_size(max_items));
> > - dead_items->max_items = max
On Fri, Mar 22, 2024 at 12:09 AM Nathan Bossart
wrote:
>
> On Thu, Mar 21, 2024 at 11:30:30AM +0700, John Naylor wrote:
> > If this were "<=" then the for long arrays we could assume there is
> > always more than one block, and wouldn't need to check if any ele
On Mon, Mar 25, 2024 at 8:02 AM Masahiko Sawada wrote:
>
> On Mon, Mar 25, 2024 at 1:53 AM Tom Lane wrote:
> >
> > I'm not sure why it took a couple weeks for Coverity to notice
> > ee1b30f12, but it saw it today, and it's not happy:
>
> Hmm, I've also done Coverity Scan in development but I
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 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 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 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 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 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 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 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 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 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 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 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
On Thu, Mar 14, 2024 at 8:53 AM Masahiko Sawada wrote:
>
> On Thu, Mar 14, 2024 at 9:59 AM John Naylor wrote:
> > > BTW do we still want to test the tidstore by using a combination of
> > > SQL functions? We might no longer need to input TIDs via a SQL
> > >
On Wed, Mar 13, 2024 at 9:29 PM Masahiko Sawada wrote:
>
> On Wed, Mar 13, 2024 at 8:05 PM John Naylor wrote:
> >
> > On Wed, Mar 13, 2024 at 8:39 AM Masahiko Sawada
> > wrote:
> >
> > > As I mentioned above, if we implement the test cases in C,
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 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 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 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 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 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, 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:
>
> --- a/src/test/modules/test_radixtree/meson.build
> +++ b/src/test/modules/test_radixtree/meson.build
> @@ -12,6 +12,7 @@ endif
>
>
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 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 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 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 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 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 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 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 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
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 Wed, Mar 6, 2024 at 3:40 PM Masahiko Sawada wrote:
>
> On Wed, Mar 6, 2024 at 5:33 PM John Naylor wrote:
> > I've looked around and it seems clang is more lax on conversions.
> > Since it works fine for clang, I think we just need a cast here for
> > gcc. I've
On Wed, Mar 6, 2024 at 3:02 PM Masahiko Sawada wrote:
>
> ../../src/include/port/simd.h:326:71: error: incompatible type for
> argument 1 of \342\200\230vshrq_n_s8\342\200\231
> uint8x16_t masked = vandq_u8(vld1q_u8(mask), (uint8x16_t) vshrq_n_s8(v, 7));
>
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...
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 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 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
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 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 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
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 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 Mon, Feb 19, 2024 at 9:02 AM Masahiko Sawada wrote:
>
> I think that vacuum and tidbitmap (and future users) would end up
> having the same max block size calculation. And it seems slightly odd
> layering to me that max-block-size-specified context is created on
> vacuum (or tidbitmap) layer,
On Fri, Feb 16, 2024 at 10:05 AM Masahiko Sawada 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 in the last level child pointer. It's not polished, but I'll
> > only proceed with
v61 had a brown-paper-bag bug in the embedded tids patch that didn't
present in the tidstore test, but caused vacuum to fail, fixed in v62.
v62-ART.tar.gz
Description: application/gzip
On Thu, Feb 15, 2024 at 10:21 AM Masahiko Sawada wrote:
>
> On Sat, Feb 10, 2024 at 9:29 PM John Naylor wrote:
> I've also run the same scripts in my environment just in case and got
> similar results:
Thanks for testing, looks good as well.
> > There are still some micro-b
On Tue, Feb 6, 2024 at 9:58 AM Masahiko Sawada wrote:
>
> On Fri, Feb 2, 2024 at 8:47 PM John Naylor wrote:
> > My todo:
> > - benchmark tid store / vacuum again, since we haven't since varlen
> > types and removing unnecessary locks.
I ran a vacuum benchmark
On Wed, Feb 7, 2024 at 11:52 PM Greg Sabino Mullane wrote:
>
> No drawbacks. I've been using it heavily for many, many years. Came out in
> 5.10.1,
> which should be available everywhere at this point (2009 was the year of
> release)
We moved our minimum to 5.14 fairly recently, so we're good
On Wed, Feb 7, 2024 at 10:41 PM Peter Eisentraut wrote:
>
> /tmp/cirrus-ci-build/src/include/common/hashfn_unstable.h: In function
> ‘int fasthash_accum_cstring_unaligned(fasthash_state*, const char*)’:
> /tmp/cirrus-ci-build/src/include/common/hashfn_unstable.h:201:20:
> warning: comparison of
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 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
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
& ((~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 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)
On Tue, Jan 23, 2024 at 10:58 AM Masahiko Sawada wrote:
>
> The new patches probably need to be polished but the VacDeadItemInfo
> idea looks good to me.
That idea looks good to me, too. Since you already likely know what
you'd like to polish, I don't have much to say except for a few
questions
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, 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
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?
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.
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
1 - 100 of 1335 matches
Mail list logo
