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.
>
> The new tests look
On Tue, Mar 5, 2024 at 6:41 PM John Naylor wrote:
>
> On Tue, Feb 6, 2024 at 9:58 AM Masahiko Sawada wrote:
> >
> > On Fri, Feb 2, 2024 at 8:47 PM John Naylor wrote:
>
> > > It's pretty hard to see what test_pattern() is doing, or why it's
> > > useful. I wonder if instead the test could use
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
> > > for callers that the dsa_area passed
On Mon, Mar 4, 2024 at 8:48 PM John Naylor wrote:
>
> 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
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
> > context, and we don't have to know
On Sun, Mar 3, 2024 at 2:43 PM John Naylor wrote:
>
> 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
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 a bit strange -- maybe look at some other
> > context
On Thu, Feb 29, 2024 at 8:43 PM John Naylor wrote:
>
> 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;
> +
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 7:47 PM John Naylor wrote:
>
> 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
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 12:41 PM John Naylor wrote:
>
> 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
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
On Thu, Feb 15, 2024 at 8:26 PM John Naylor wrote:
>
> 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,
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-benchmarks we could
On Sat, Feb 10, 2024 at 9:29 PM John Naylor wrote:
>
> 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
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 similar to the one in [1]
On Fri, Feb 2, 2024 at 8:47 PM John Naylor wrote:
>
> 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:
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
On Tue, Jan 30, 2024 at 7:20 PM John Naylor wrote:
>
> 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).
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 your question earlier
> > about block
On Mon, Jan 29, 2024 at 8:48 PM John Naylor wrote:
>
> 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
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 Fri, Jan 26, 2024 at 11:05 PM Masahiko Sawada wrote:
>
> On Wed, Jan 24, 2024 at 3:42 PM John Naylor wrote:
> >
> > 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.
> >
>
On Wed, Jan 24, 2024 at 3:42 PM John Naylor wrote:
>
> 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
>
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 Tue, Jan 23, 2024 at 12:58 PM Masahiko Sawada wrote:
>
> On Mon, Jan 22, 2024 at 5:18 PM John Naylor wrote:
> >
> > 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
On Mon, Jan 22, 2024 at 5:18 PM John Naylor wrote:
>
> 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
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, Jan 22, 2024 at 2:36 PM John Naylor wrote:
>
> 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".
On Wed, Jan 17, 2024 at 12:32 PM John Naylor wrote:
>
> 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"
>
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 Fri, Jan 19, 2024 at 6:48 PM John Naylor wrote:
>
> On Fri, Jan 19, 2024 at 2:26 PM Masahiko Sawada wrote:
> >
> > On Thu, Jan 18, 2024 at 1:30 PM John Naylor wrote:
> > > I'm not quite sure what the point of "num_items" is anymore, because
> > > it was really tied to the array in
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 Fri, Jan 19, 2024 at 2:26 PM Masahiko Sawada wrote:
>
> On Thu, Jan 18, 2024 at 1:30 PM John Naylor wrote:
> > I'm not quite sure what the point of "num_items" is anymore, because
> > it was really tied to the array in VacDeadItems. dead_items->num_items
> > is essential to reading/writing
On Thu, Jan 18, 2024 at 1:30 PM John Naylor wrote:
>
> On Thu, Jan 18, 2024 at 8:31 AM Masahiko Sawada wrote:
> > It seems we cannot make this work nicely. IIUC VacDeadItems is
> > allocated in DSM and TidStore is embedded there. However,
> > dead_items->items.area is a local pointer to
On Thu, Jan 18, 2024 at 8:31 AM Masahiko Sawada wrote:
> It seems we cannot make this work nicely. IIUC VacDeadItems is
> allocated in DSM and TidStore is embedded there. However,
> dead_items->items.area is a local pointer to dsa_area. So we cannot
> include dsa_area in neither TidStore nor
On Wed, Jan 17, 2024 at 11:37 AM John Naylor wrote:
>
> 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
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
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 the
> > > code tricky a bit, since max_bytes
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 the
> > code tricky a bit, since max_bytes and num_items are on the shared
> > memory while "items" is a local
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 Sun, Jan 14, 2024 at 10:43 PM John Naylor wrote:
>
> On Fri, Jan 12, 2024 at 3:49 PM Masahiko Sawada wrote:
> >
> > On Thu, Jan 11, 2024 at 9:28 AM Masahiko Sawada
> > wrote:
> > > So I agree to remove both max_bytes and num_items from the control
> > > object.Also, as you mentioned, we can
On Fri, Jan 12, 2024 at 3:49 PM Masahiko Sawada wrote:
>
> On Thu, Jan 11, 2024 at 9:28 AM Masahiko Sawada wrote:
> > So I agree to remove both max_bytes and num_items from the control
> > object.Also, as you mentioned, we can remove the tidstore control
> > object itself. TidStoreGetHandle()
On Thu, Jan 11, 2024 at 9:28 AM Masahiko Sawada wrote:
>
> On Mon, Jan 8, 2024 at 8:35 PM John Naylor wrote:
> >
> > On Wed, Jan 3, 2024 at 9:10 PM John Naylor wrote:
> > >
> > > On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada
> > > wrote:
> > >
> > > > I agree that we expose RT_LOCK_*
On Mon, Jan 8, 2024 at 8:35 PM John Naylor wrote:
>
> On Wed, Jan 3, 2024 at 9:10 PM John Naylor wrote:
> >
> > On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada
> > wrote:
> >
> > > I agree that we expose RT_LOCK_* functions and have tidstore use them,
> > > but am not sure the if
On Wed, Jan 10, 2024 at 9:05 AM Masahiko Sawada wrote:
>
> I've done in 0010 patch in v51 patch set. Whereas RT_NODE_4 and
> RT_NODE_16 structs declaration needs RT_FANOUT_4_HI and
> RT_FANOUT_16_HI respectively, RT_FANOUT_16_LO and RT_FANOUT_48 need
> RT_NODE_16 and RT_NODE_48 structs
On Tue, Jan 9, 2024 at 8:19 PM John Naylor wrote:
>
> On Tue, Jan 9, 2024 at 9:40 AM Masahiko Sawada wrote:
> > In addition, I've made some changes and cleanups:
>
> These look good to me, although I have not tried dumping a node in a while.
>
> > 0011 - simplify the radix tree iteration code. I
On Tue, Jan 9, 2024 at 9:40 AM Masahiko Sawada wrote:
> In addition, I've made some changes and cleanups:
These look good to me, although I have not tried dumping a node in a while.
> 0011 - simplify the radix tree iteration code. I hope it makes the
> code clear and readable. Also I removed
On Wed, Jan 3, 2024 at 11:10 PM John Naylor wrote:
>
> On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada wrote:
>
> > I agree that we expose RT_LOCK_* functions and have tidstore use them,
> > but am not sure the if (TidStoreIsShared(ts) LWLockAcquire(..., ...)"
> > calls part. I think that even if
On Wed, Jan 3, 2024 at 9:10 PM John Naylor wrote:
>
> On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada wrote:
>
> > I agree that we expose RT_LOCK_* functions and have tidstore use them,
> > but am not sure the if (TidStoreIsShared(ts) LWLockAcquire(..., ...)"
> > calls part. I think that even if
On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada wrote:
> I agree that we expose RT_LOCK_* functions and have tidstore use them,
> but am not sure the if (TidStoreIsShared(ts) LWLockAcquire(..., ...)"
> calls part. I think that even if we expose them, we will still need to
> do something like "if
On Wed, Dec 27, 2023 at 12:08 PM John Naylor wrote:
>
> On Tue, Dec 26, 2023 at 12:43 PM Masahiko Sawada
> wrote:
> >
> > On Thu, Dec 21, 2023 at 4:41 PM John Naylor wrote:
>
> > > +TidStoreSetBlockOffsets(TidStore *ts, BlockNumber blkno, OffsetNumber
> > > *offsets,
> > > + int num_offsets)
On Tue, Dec 26, 2023 at 12:43 PM Masahiko Sawada wrote:
>
> On Thu, Dec 21, 2023 at 4:41 PM John Naylor wrote:
> > +TidStoreSetBlockOffsets(TidStore *ts, BlockNumber blkno, OffsetNumber
> > *offsets,
> > + int num_offsets)
> > +{
> > + char buf[MaxBlocktableEntrySize];
> > + BlocktableEntry
On Thu, Dec 21, 2023 at 4:41 PM John Naylor wrote:
>
> On Thu, Dec 21, 2023 at 8:33 AM Masahiko Sawada wrote:
> >
> > I found the following comment and wanted to discuss:
> >
> > // this might be better as "iterate over nodes", plus a callback to
> > RT_DUMP_NODE,
> > // which should really only
On Thu, Dec 21, 2023 at 6:27 PM Andres Freund wrote:
>
> Could either of you summarize what the design changes you've made in the last
> months are and why you've done them? Unfortunately this thread is very long,
> and the comments in the file just say "FIXME" in places that apparently are
>
Hi,
On 2023-12-21 14:41:37 +0700, John Naylor wrote:
> I've attached v47, which is v46 plus some fixes for radix tree.
Could either of you summarize what the design changes you've made in the last
months are and why you've done them? Unfortunately this thread is very long,
and the comments in
On Thu, Dec 21, 2023 at 8:33 AM Masahiko Sawada wrote:
>
> I found the following comment and wanted to discuss:
>
> // this might be better as "iterate over nodes", plus a callback to
> RT_DUMP_NODE,
> // which should really only concern itself with single nodes
> RT_SCOPE void
>
On Thu, Dec 21, 2023 at 10:19 AM John Naylor wrote:
>
> On Wed, Dec 20, 2023 at 6:36 PM Masahiko Sawada wrote:
> >
> > I've updated the new patch set that incorporated comments I got so
> > far. 0007, 0008, and 0012 patches are updates from the v45 patch set.
> > In addition to the review
On Wed, Dec 20, 2023 at 6:36 PM Masahiko Sawada wrote:
>
> I've updated the new patch set that incorporated comments I got so
> far. 0007, 0008, and 0012 patches are updates from the v45 patch set.
> In addition to the review comments, I made some changes in tidstore to
> make it independent from
On Tue, Dec 19, 2023 at 4:37 PM John Naylor wrote:
>
> On Tue, Dec 19, 2023 at 12:37 PM Masahiko Sawada
> wrote:
> >
> > On Mon, Dec 18, 2023 at 3:41 PM John Naylor wrote:
> > > Let's do it in just one place. In TidStoreCreate(), do
> > >
> > > /* clamp max_bytes to at least the size of the
On Tue, Dec 19, 2023 at 12:37 PM Masahiko Sawada wrote:
>
> On Mon, Dec 18, 2023 at 3:41 PM John Naylor wrote:
> > Let's do it in just one place. In TidStoreCreate(), do
> >
> > /* clamp max_bytes to at least the size of the empty tree with
> > allocated blocks, so it doesn't immediately appear
On Mon, Dec 18, 2023 at 3:41 PM John Naylor wrote:
>
> On Fri, Dec 15, 2023 at 3:15 PM Masahiko Sawada wrote:
> >
> > On Fri, Dec 15, 2023 at 10:30 AM John Naylor
> > wrote:
>
> > > parallel_vacuum_init(Relation rel, Relation *indrels, int nindexes,
> > > - int nrequested_workers, int
On Fri, Dec 15, 2023 at 3:15 PM Masahiko Sawada wrote:
>
> On Fri, Dec 15, 2023 at 10:30 AM John Naylor wrote:
> > parallel_vacuum_init(Relation rel, Relation *indrels, int nindexes,
> > - int nrequested_workers, int max_items,
> > - int elevel, BufferAccessStrategy bstrategy)
> > + int
On Fri, Dec 15, 2023 at 10:30 AM John Naylor wrote:
>
> On Thu, Dec 14, 2023 at 7:22 AM Masahiko Sawada wrote:
> > In v45, 0001 - 0006 are from earlier versions but I've merged previous
> > updates. So the radix tree now has RT_SET() and RT_FIND() but not
> > RT_GET() and RT_SEARCH(). 0007 and
On Thu, Dec 14, 2023 at 7:22 AM Masahiko Sawada wrote:
> In v45, 0001 - 0006 are from earlier versions but I've merged previous
> updates. So the radix tree now has RT_SET() and RT_FIND() but not
> RT_GET() and RT_SEARCH(). 0007 and 0008 are the updates from previous
> versions that incorporated
On Tue, Dec 12, 2023 at 11:53 AM John Naylor wrote:
>
> On Mon, Dec 11, 2023 at 1:18 PM Masahiko Sawada wrote:
>
> > I've attached the updated patch set. From the previous patch set, I've
> > merged patches 0007 to 0010. The other changes such as adding RT_GET()
> > still are unmerged for now,
On Mon, Dec 11, 2023 at 1:18 PM Masahiko Sawada wrote:
> I've attached the updated patch set. From the previous patch set, I've
> merged patches 0007 to 0010. The other changes such as adding RT_GET()
> still are unmerged for now, for discussion. Probably we can make them
> as follow-up patches
On Fri, Dec 8, 2023 at 9:44 PM Masahiko Sawada wrote:
>
> On Fri, Dec 8, 2023 at 7:46 PM John Naylor wrote:
> >
> > 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
On Fri, Dec 8, 2023 at 7:46 PM John Naylor wrote:
>
> 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
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 Fri, Dec 8, 2023 at 3:45 PM Masahiko Sawada wrote:
>
> On Fri, Dec 8, 2023 at 1:37 PM John Naylor wrote:
> >
> > 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
On Fri, Dec 8, 2023 at 1:37 PM John Naylor wrote:
>
> 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
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 Thu, Dec 7, 2023 at 12:27 PM John Naylor wrote:
>
> 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,
> >
On Wed, Dec 6, 2023 at 3:39 PM John Naylor wrote:
>
> 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
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_VALUE_TYPE *value_p,
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, but it cannot as the radix tree
On Mon, Dec 4, 2023 at 5:21 PM John Naylor wrote:
>
> 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
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 Sat, Oct 28, 2023 at 5:56 PM John Naylor wrote:
>
> 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
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
On Sat, Sep 16, 2023 at 9:03 AM Andres Freund wrote:
>
> Hi,
>
> On 2023-08-28 23:43:22 +0900, Masahiko Sawada wrote:
> > I've attached v42 patch set. I improved tidstore regression test codes
> > in addition of imcorporating the above comments.
>
> Why did you need to disable the benchmark
Hi,
On 2023-08-28 23:43:22 +0900, Masahiko Sawada wrote:
> I've attached v42 patch set. I improved tidstore regression test codes
> in addition of imcorporating the above comments.
Why did you need to disable the benchmark module for CI?
Greetings,
Andres Freund
On Wed, Sep 6, 2023 at 3:23 PM John Naylor wrote:
>
>
> On Mon, Aug 28, 2023 at 9:44 PM Masahiko Sawada wrote:
> >
> > I've attached v42 patch set. I improved tidstore regression test codes
> > in addition of imcorporating the above comments.
>
> Seems fine at a glance, thanks. I will build on
On Mon, Aug 28, 2023 at 9:44 PM Masahiko Sawada
wrote:
>
> I've attached v42 patch set. I improved tidstore regression test codes
> in addition of imcorporating the above comments.
Seems fine at a glance, thanks. I will build on this to implement
variable-length values. I have already finished
On Mon, Aug 28, 2023 at 4:20 PM John Naylor
wrote:
>
> On Sun, Aug 27, 2023 at 7:53 PM Masahiko Sawada wrote:
> >
> > I've updated the regression tests for tidstore so that it uses SQL
> > functions to add blocks/offsets and dump its contents. The new test
> > covers the same test coverages but
On Sun, Aug 27, 2023 at 7:53 PM Masahiko Sawada
wrote:
>
> I've updated the regression tests for tidstore so that it uses SQL
> functions to add blocks/offsets and dump its contents. The new test
> covers the same test coverages but it's executed using SQL functions
> instead of executing all
On Wed, Aug 16, 2023 at 8:04 PM John Naylor
wrote:
>
>
> On Tue, Aug 15, 2023 at 6:53 PM John Naylor
> wrote:
> >
> > On Tue, Aug 15, 2023 at 9:34 AM Masahiko Sawada
> > wrote:
> >
> > > BTW cfbot reported that some regression tests failed due to OOM. I've
> > > attached the patch to fix it.
On Tue, Aug 15, 2023 at 6:53 PM John Naylor
wrote:
>
> On Tue, Aug 15, 2023 at 9:34 AM Masahiko Sawada
wrote:
>
> > BTW cfbot reported that some regression tests failed due to OOM. I've
> > attached the patch to fix it.
>
> Seems worth doing now rather than later, so added this and squashed most
On Tue, Aug 15, 2023 at 9:34 AM Masahiko Sawada
wrote:
> BTW cfbot reported that some regression tests failed due to OOM. I've
> attached the patch to fix it.
Seems worth doing now rather than later, so added this and squashed most of
the rest together. I wonder if that test uses too much
Hi,
On Mon, Aug 14, 2023 at 8:05 PM John Naylor
wrote:
>
> On Thu, Jul 13, 2023 at 3:09 PM Masahiko Sawada wrote:
> >
> > 0007, 0008, 0010, and 0011 are straightforward and agree to merge them.
Thank you for updating the patch!
>
> [Part 1 - clear the deck of earlier performance work etc]
>
>
On Thu, Jul 13, 2023 at 3:09 PM Masahiko Sawada
wrote:
>
> 0007, 0008, 0010, and 0011 are straightforward and agree to merge them.
[Part 1 - clear the deck of earlier performance work etc]
Thanks for taking a look! I've merged 0007 and 0008. The others need a
performance test to justify them --
Hi,
On Thu, Jul 13, 2023 at 5:08 PM Masahiko Sawada wrote:
>
> On Sat, Jul 8, 2023 at 11:54 AM John Naylor
> wrote:
> >
> >
> > On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jul 5, 2023 at 8:21 PM John Naylor
> > > wrote:
> > > > Well, it's going to be a bit
On Sat, Jul 8, 2023 at 11:54 AM John Naylor
wrote:
>
>
> On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada wrote:
> >
> > On Wed, Jul 5, 2023 at 8:21 PM John Naylor
> > wrote:
> > > Well, it's going to be a bit of a mess until I can demonstrate it working
> > > (and working well) with bitmap
On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada
wrote:
>
> On Wed, Jul 5, 2023 at 8:21 PM John Naylor
wrote:
> > Well, it's going to be a bit of a mess until I can demonstrate it
working (and working well) with bitmap heap scan. Fixing that now is just
going to create conflicts. I do have a
On Wed, Jul 5, 2023 at 8:21 PM John Naylor wrote:
>
> On Tue, Jul 4, 2023 at 12:49 PM Masahiko Sawada wrote:
> >
> > As you mentioned, the 1-byte value is embedded into 8 byte so 7 bytes
> > are unused, but we use less memory since we use less slab contexts and
> > save fragmentations.
>
>
101 - 200 of 435 matches
Mail list logo
