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
On Sun, Dec 10, 2023 at 2:18 AM Jeff Davis wrote:
>
> On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > > I tested using the new hash function APIs for my search path cache,
> > > and
> > > there's a significant speedup for cases not benefiting fr
I wrote:
> On Sun, Dec 10, 2023 at 2:18 AM Jeff Davis wrote:
> >
> > On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > > > I tested using the new hash function APIs for my search path cache,
> > > > and
> > > > there&#x
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 a
On Sun, Dec 10, 2023 at 2:18 AM Jeff Davis wrote:
>
> On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > > I tested using the new hash function APIs for my search path cache,
> > > and
> > > there's a significant speedup for cases not benefiting fr
I wrote:
>
> * v8 with chunked interface:
> latency average = 555.688 ms
>
> This starts to improve things for me.
>
> * v8 with chunked, and return lower 32 bits of full 64-bit hash:
> latency average = 556.324 ms
>
> This is within the noise level. There doesn't seem to be much downside
> of usin
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 t
g buried in an earlier version: use in
pgstat. Looks nicer, but not yet tested.
From aecbc51780ada4634855727c50e3b85a8f7f Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Sat, 9 Dec 2023 16:24:56 +0700
Subject: [PATCH v10 3/3] Use fasthash32 for pgstat_hash_hash_key
Currently this calls the
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, BufferAccessStrat
On Tue, Dec 5, 2023 at 3:27 AM Tristan Partin wrote:
>
> On Mon Dec 4, 2023 at 2:10 PM CST, Tom Lane wrote:
> > Not sure what you were using, but are you aware that SQL access to the
> > buildfarm database is available to project members? My own stock
> > approach to checking on this sort of thin
On Fri, Dec 15, 2023 at 5:44 AM Tom Lane wrote:
>
> I did check that the v1 patch successfully inlines newNode() and
> reduces it to just a MemoryContextAllocZeroAligned call, so it's
> correct that modern compilers do that better than whatever I tested
> in 2008. But I wonder what is happening i
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 block
On Tue, Dec 19, 2023 at 2:32 PM Jeff Davis wrote:
>
> On Mon, 2023-12-18 at 13:39 +0700, John Naylor wrote:
> > For now just two:
> > v10-0002 is Jeff's change to the search path cache, but with the
> > chunked interface that I found to be faster.
>
> Did you co
On Wed, Dec 20, 2023 at 3:23 AM Jeff Davis wrote:
>
> On Tue, 2023-12-19 at 16:23 +0700, John Naylor wrote:
> > That wasn't the next place I thought to look (that would be the
> > strcmp
> > call), but something like this could be worthwhile.
>
> The reason I
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 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
> RT_DUMP(RT_RADIX_
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
> affe
On Sat, Dec 23, 2023 at 5:26 AM Przemysław Sztoch wrote:
>
> In my opinion date_trunc is very good name.
> Truncated data is timestamp type, not interval.
> First parameter has same meaning in original date_trunc and in my new version.
> New version provides only more granularity.
I haven't looke
On Fri, Dec 22, 2023 at 1:50 PM Kyotaro Horiguchi
wrote:
>
> I found the following message introduced by a recent commit.
>
> > errdetail("The first unsummarized LSN is this range is %X/%X.",
>
> Shouldn't the "is" following "LSN" be "in"?
I think you're right, will push.
On Wed, Dec 20, 2023 at 1:48 PM John Naylor wrote:
>
> On Wed, Dec 20, 2023 at 3:23 AM Jeff Davis wrote:
> >
> > The reason I looked here is that the inner while statement (to find the
> > chunk size) looked out of place and possibly slow, and there's a
> &g
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[MaxBlockta
On Fri, Dec 22, 2023 at 1:50 PM Kyotaro Horiguchi
wrote:
>
> I found the following message introduced by a recent commit.
>
> > errdetail("The first unsummarized LSN is this range is %X/%X.",
>
> Shouldn't the "is" following "LSN" be "in"?
Pushed.
On Mon, Dec 25, 2023 at 12:51 PM Kyotaro Horiguchi
wrote:
>
> A new function check_control_file() in pg_combinebackup.c has the
> following message.
>
> > pg_fatal("%s: crc is incorrect", controlpath);
>
> I think "crc" should be in all uppercase in general and a brief
> grep
On Thu, Dec 28, 2023 at 1:20 AM Tristan Partin wrote:
> I recently wound up in a situation where I was checking for NULL return
> values of a function that couldn't ever return NULL because the
> inability to allocate memory was always elog(ERROR)ed (aborted).
It sounds like you have a ready exam
On Thu, Nov 30, 2023 at 12:15 AM Nathan Bossart
wrote:
> I don't intend for this patch to be
> seriously considered until we have better support for detecting/compiling
> AVX2 instructions and a buildfarm machine that uses them.
That's completely understandable, yet I'm confused why there is a
co
On Thu, Dec 28, 2023 at 12:27 PM Shubham Khanna
wrote:
>
> I was reviewing the Patch and came across a minor issue that the Patch
> does not apply on the current Head. Please provide the updated version
> of the patch.
For your information, the commitfest manager has the ability to send
private m
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 Tue, Jan 2, 2024 at 6:56 AM jian he wrote:
>
> My local computer is slow. but here is the test results:
>
> select * from bench_cstring_hash_aligned(10);7318.893 ms
> select * from bench_cstring_hash_unaligned(10);10383.173 ms
> select * from bench_pgstat_hash(10);
On Tue, Jan 2, 2024 at 11:11 PM Nathan Bossart wrote:
>
> Perhaps I was too optimistic about adding support for newer instructions...
>
> I'm tempted to propose that we move forward with this patch as-is after
> adding a buildfarm machine that compiles with -mavx2 or -march=x86-64-v3.
That means
On Wed, Jan 3, 2024 at 10:29 PM Nathan Bossart wrote:
> If the requirement is that normal builds use AVX2, then I fear we will be
> waiting a long time. IIUC the current proposals (building multiple
> binaries or adding a configuration option that maps to compiler flags)
> would still be opt-in,
broken makefile from the benchmark (not for commit anyway)
From cf64f9a0603837dd89efdf1aa455395906e75ded Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Fri, 5 Jan 2024 17:21:53 +0700
Subject: [PATCH v13 5/6] WIP: a safer way to accumulate a single struct member
into the hash state
---
s
On Fri, Jan 5, 2024 at 6:58 PM jian he wrote:
> -Dcassert=true \
> -Dbuildtype=debug \
These probably don't matter much for this test, but these should be
off for any performance testing.
> -DWRITE_READ_PARSE_PLAN_TREES
> -DCOPY_PARSE_PLAN_TREES
>
On Sat, Jan 6, 2024 at 9:01 AM jian he wrote:
>
> latency average = 147.782 ms
> select * from bench_cstring_hash_unaligned(10);
> latency average = 101.179 ms
> select * from bench_cstring_hash_aligned(10);
> latency average = 101.219 ms
Thanks for testing again! This looks closer to my
On Thu, Nov 30, 2023 at 12:15 AM Nathan Bossart
wrote:
> Using the same benchmark as we did for the SSE2 linear searches in
> XidInMVCCSnapshot() (commit 37a6e5d) [1] [2], I see the following:
I've been antagonistic towards the patch itself, but it'd be more
productive if I paid some nuanced att
On Sat, Jan 6, 2024 at 12:04 AM Nathan Bossart wrote:
> I've been thinking about the configuration option approach. ISTM that
> would be the most feasible strategy, at least for v17. A couple things
> come to mind:
>
> * This option would simply map to existing compiler flags. We already have
On Mon, Jan 8, 2024 at 2:24 PM Junwang Zhao wrote:
>
> + * Portions Copyright (c) 2018-2023, PostgreSQL Global Development Group
>
> A kind reminder, it's already 2024 :)
>
> I'm also curious why the 2018, is there any convention for that?
The convention I followed was "blind copy-paste", but the
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(..., ...)"
> >
On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart wrote:
>
> > I suspect that there could be a regression lurking for some inputs
> > that the benchmark doesn't look at: pg_lfind32() currently needs to be
> > able to read 4 vector registers worth of elements before taking the
> > fast path. There is
On Mon, Oct 30, 2023 at 2:21 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> How about adding code indent checks (like what BF member koel has) to
> the SanityCheck CI task? This helps catch indentation problems way
> before things are committed so that developers can find them out in
> their respective C
On Thu, Dec 28, 2023 at 7:58 PM Ranier Vilela wrote:
> I think it would be more productive to initialize the entire array with -1,
> and avoid flagging, one by one, the items that should be -1.
This just moves an operation from one place to the other, while
obliterating the explanatory comment,
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 RT_
On Tue, Jan 9, 2024 at 11:20 PM Nathan Bossart wrote:
>
> On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote:
> > On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart
> > wrote:
> >>
> >> > I suspect that there could be a regression lurking for some i
On Wed, Jan 10, 2024 at 2:20 AM Tristan Partin wrote:
>
> On Tue Jan 9, 2024 at 3:00 AM CST, John Naylor wrote:
> > I don't indent during most of development, and don't intend to start.
>
> Could you expand on why you don't? I could understand as you're writ
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 declaratio
On Thu, Nov 2, 2023 at 4:13 AM Peter Eisentraut wrote:
>
> Here is a rebased patch set, along with a summary of the questions I
> have about these patches:
This is an excellent summary of the issues, thanks.
> v4-0001-Generate-syscache-info-from-catalog-files.patch
>
> What's a good syntax to de
On Wed, Oct 5, 2022 at 1:46 PM Masahiko Sawada
wrote:
>
> On Wed, Sep 28, 2022 at 12:49 PM Masahiko Sawada
wrote:
> >
> > On Fri, Sep 23, 2022 at 12:11 AM John Naylor
> > wrote:
> > Yeah, node31 and node256 are bloated. We probably could use slab for
> &g
On Thu, Oct 6, 2022 at 2:53 PM Masahiko Sawada
wrote:
>
> On Wed, Oct 5, 2022 at 6:40 PM John Naylor
wrote:
> >
> > This wasn't the focus of your current email, but while experimenting
with v6 I had another thought about local allocation: If we use the default
slab block s
ted | rt_load_ms |
array_load_ms | rt_search_ms | array_serach_ms
-+--+-++---+--+-
100 | 10199040 | 180000000 | 171 |
107 | 827 |1400
--
John Naylor
EDB: http://www.enterprised
ed.
Not necessarily. We don't have to shrink at the same granularity as
growing. My evidence is simple: we don't shrink at all now. :-)
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Oct 10, 2022 at 12:16 PM John Naylor
wrote:
> Thanks for that! Now I can show clear results on some aspects in a simple
way. The attached patches (apply on top of v6)
Forgot the patchset...
--
John Naylor
EDB: http://www.enterprisedb.com
radix-v6-addendum-jcn1.tar.gz
Descript
> You mean semi-colon? +1, and a quick regex later I don't see any other
> occurrence.
Interestingly, I did find that in C, some statement is needed after a
label, even an empty one, otherwise it won't compile. That's not the case
here, though, so pushed.
--
John Naylor
EDB: http://www.enterprisedb.com
, I have proposed in that thread a scheme to squeeze
things into power-of-two sizes without wasting quite as much space. That's
not a done deal, of course, but it could work today without adding memory
management code.
[1]
https://www.postgresql.org/message-id/20220704220038.at2ane5xkymzzssb%40awor
On Sat, Sep 17, 2022 at 12:29 PM Nathan Bossart
wrote:
>
> On Fri, Sep 16, 2022 at 02:54:14PM +0700, John Naylor wrote:
> > v6 demonstrates why this should have been put off towards the end.
(more below)
>
> Since the SIMD code is fresh in my mind, I wanted to offer my review
nds on SSE4.2. We can't assume those
currently.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Oct 20, 2022 at 1:55 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-10-11 10:21:17 +0700, John Naylor wrote:
> > On Tue, Oct 11, 2022 at 5:31 AM David Rowley
wrote:
> > >
> > > The proposed patches in [1] do aim to make additional usages of the
> &
at the behavior is.
> I also took the chance to simplify the code a little bit.
It's perfectly clear and simple now, even if it doesn't win at "code golf".
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Oct 25, 2022 at 9:48 AM Richard Guo wrote:
>
>
> On Tue, Oct 25, 2022 at 10:05 AM John Naylor
wrote:
>>
>> It's perfectly clear and simple now, even if it doesn't win at "code
golf".
>
>
> Agree with your point. Do you think we can
ut not hard-coded) at
the top:
if (count > 4)
pg_unreachable();
This would have to change when we implement shrinking of nodes, but might
still be useful.
+ if (!rt_node_search_leaf(node, key, RT_ACTION_FIND, value_p))
+ return false;
+
+ return true;
Maybe just "return rt_node_search_leaf(...)" ?
--
John Naylor
EDB: http://www.enterprisedb.com
the compiler know
that? I believe it boils down to
static rt_node_kind_info_elem rt_node_kind_info[RT_NODE_KIND_COUNT] = {
In the assembly, I see it checks if there is room in the node by doing a
runtime lookup in this array, which is not constant. This might not be
important just yet, because
naive user -- it would be good to try
running everything documented here.
--
John Naylor
EDB: http://www.enterprisedb.com
read is sound enough to justify working further on.
[1] https://www.cs.rochester.edu/u/sandhya/papers/ispass19.pdf
(paper: "On the Impact of Instruction Address Translation Overhead")
[2] https://twitter.com/AndresFreundTec/status/1214305610172289024
[3] https://github.com/intel/iodlr
gt; > there.
>
> Agreed, it's apparently an oversight in dac048f71eb. +1 for the patch.
Yeah. +1, thanks.
--
John Naylor
EDB: http://www.enterprisedb.com
We don't need to go that far for v16 of course, but what's the
simplest thing we can do to make that possible? Other use cases can change
to more sophisticated schemes if need be.
--
John Naylor
EDB: http://www.enterprisedb.com
gt; > there.
>
> Agreed, it's apparently an oversight in dac048f71eb. +1 for the patch.
I've pushed this, thanks!
--
John Naylor
EDB: http://www.enterprisedb.com
97.303 ms
Testing a3
latency average = 955.997 ms
Testing a4
latency average = 1023.497 ms
Testing a5
latency average = 1088.494 ms
Testing a6
latency average = 1149.418 ms
Testing a7
latency average = 1213.134 ms
Testing a8
latency average = 1282.760 ms
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Nov 3, 2022 at 6:40 PM Michael Paquier wrote:
>
> On Thu, Nov 03, 2022 at 12:40:19PM +0700, John Naylor wrote:
> > On Wed, Nov 2, 2022 at 1:01 PM Julien Rouhaud
wrote:
> >> Agreed, it's apparently an oversight in dac048f71eb. +1 for the patch.
> &
On Fri, Nov 4, 2022 at 5:42 AM Michael Paquier wrote:
>
> The CI is able to complete without it. Would you mind if it is
> removed? If you don't want us to poke more at the bear, that's a nit
> so leaving things as they are is also fine by me.
I've removed it
boundary. However the OS / dynamic loader only
> maps the necessary part, not all the zero padding.
>
> This means that if we were to issue a MADV_COLLAPSE, we can before it do
an
> mremap() to increase the length of the mapping.
I see, interesting. What location are you passing for madvise() and
mremap()? The beginning of the segment (for me has .init/.plt) or an
aligned boundary within .text?
--
John Naylor
EDB: http://www.enterprisedb.com
tegration, radix tree APIs, and shared radix tree functionality.
It does help, good to see this.
--
John Naylor
EDB: http://www.enterprisedb.com
dd CC_LD=lld to the env vars before invoking, which got rid of
the warning. Then I wanted to verify that lld was actually used, and in
https://releases.llvm.org/14.0.0/tools/lld/docs/index.html
it says I can run this and it should show “Linker: LLD”, but that doesn't
appear for me:
$ readelf --string-dump .comment inst-perf/bin/postgres
String dump of section '.comment':
[ 0] GCC: (GNU) 12.2.1 20220819 (Red Hat 12.2.1-2)
--
John Naylor
EDB: http://www.enterprisedb.com
h only logs a message
> if it tries and fails?
I think the best thing to do is change huge_pages='on' to log a WARNING and
fallback to regular pages if the mapping fails. That way, both dev and prod
can keep the same settings, since 'on' will have both visibility and
robustnes
undary
*
* Note: we rely on zeroing to initialize all the dlist headers correctly
*/
sz = sizeof(CatCache) + PG_CACHE_LINE_SIZE;
cp = (CatCache *) CACHELINEALIGN(palloc0(sz));
--
John Naylor
EDB: http://www.enterprisedb.com
t PG page size, but if allocating pages on the heap is hot enough,
maybe we should consider raising that limit. Although then, aligned-to-4kB
requests would result in 16kB chunks requested unless a different allocator
was used.
--
John Naylor
EDB: http://www.enterprisedb.com
on't need to be that long, so I have tweaked these to be
> minimal, and updated a few more areas. Note that this has been split
> into two commits: one to introduce the new routine in file_utils.c and
> a second for the switch in walmethods.c.
Was there supposed to be an attachme
pense with both freelist_shift and the loop that computes it?
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Nov 11, 2022 at 2:12 PM Michael Paquier wrote:
>
> On Fri, Nov 11, 2022 at 11:53:08AM +0530, Bharath Rupireddy wrote:
> > On Fri, Nov 11, 2022 at 11:14 AM John Naylor <
john.nay...@enterprisedb.com> wrote:
> >> Was there supposed to be an attachment here?
>
it just saves a bit of boxing and
> unboxing of the redirect headers.
To my mind the main point of detecting this case is to save memory, so if
that's not possible/convenient, special-casing doesn't seem worth it.
- Assert((char *) chunk > (char *) block);
+ Assert((char *) chunk >= (char *) block);
Is this related or independent?
--
John Naylor
EDB: http://www.enterprisedb.com
ES SQL:202x draft
Is there an ETA yet?
Also, it's not this patch's job to do it, but there are at least a half
dozen places that open-code turning a hex char into a number. It might be a
good easy "todo item" to unify that.
--
John Naylor
EDB: http://www.enterprisedb.com
al functions would be duplicated.
I'll set the patch to "waiting on author", but in this case the author is
me.
--
John Naylor
EDB: http://www.enterprisedb.com
t;../src/backend/lib/radixtree.c", Line: 2186, PID: 18242
--
John Naylor
EDB: http://www.enterprisedb.com
On Wed, Nov 16, 2022 at 11:46 AM John Naylor
wrote:
>
>
> On Tue, Nov 15, 2022 at 11:59 AM Masahiko Sawada
wrote:
> > Thanks! Please let me know if there is something I can help with.
>
> I didn't get very far because the tests fail on 0004 in rt_verify_node:
>
>
On Wed, Nov 16, 2022 at 12:33 PM Masahiko Sawada
wrote:
>
> On Wed, Nov 16, 2022 at 1:46 PM John Naylor
> wrote:
> >
> >
> > On Tue, Nov 15, 2022 at 11:59 AM Masahiko Sawada
wrote:
> > > Thanks! Please let me know if there is something I can help with.
>
ething like debug_parallel_query is much less likely to be
misused.
+1 on both points.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Jan 30, 2023 at 10:07 PM Bruce Momjian wrote:
>
> On Mon, Jan 30, 2023 at 01:13:45PM +0700, John Naylor wrote:
> > "It's worth checking if the feature of interest is found in the TODO
list on
> > our wiki: http://wiki.postgresql.org/wiki/TODO. The entries the
701 - 800 of 1471 matches
Mail list logo
