On Wed, Apr 6, 2022 at 10:00 AM Andres Freund wrote:
> - while working on the above point, I noticed that hash_bytes() showed up
> noticeably in profiles, so I replaced it with a fixed-width function
I'm curious about this -- could you direct me to which patch introduces this?
--
John
On Thu, Apr 14, 2022 at 1:46 PM David Rowley wrote:
>
> On Wed, 13 Apr 2022 at 23:19, John Naylor
> wrote:
> > More broadly than the regression, Thomas' is very often the fastest of
> > all, at the cost of more binary size. David's is occasionally slower
> >
0a85 from today removes another source of overhead in this
function, so I suggest testing against that, if you wish to test again.
--
John Naylor
EDB: http://www.enterprisedb.com
finished one prerequisite which is:
public APIs passing pointers to values.
--
John Naylor
EDB: http://www.enterprisedb.com
oesn't do so for me.
>
> Are you saying that the desired constant folding happened after combining
the
> branches, or that it didn't happen?
Constant folding did not happen.
--
John Naylor
EDB: http://www.enterprisedb.com
compilers will show some
improvement with either patch.)
If you agree, do you want to withdraw your patch from the commit fest?
--
John Naylor
EDB: http://www.enterprisedb.com
ell as convincing others that the change is important.
--
John Naylor
EDB: http://www.enterprisedb.com
scan->rs_ntuples = heapgetpage_collect(scan, snapshot, page, buffer,
+ block, lines, 0, 1);
I believe we prefer true/false rather than numbers.
--
John Naylor
EDB: http://www.enterprisedb.com
CF entry has been withdrawn, after the author looked
at this one and did some testing.
--
John Naylor
EDB: http://www.enterprisedb.com
he ideas I mentioned earlier.
(not changing CF status, because nothing specific is really required to
change at the moment, some things up in the air)
--
John Naylor
EDB: http://www.enterprisedb.com
isn't reliable, but it happens to work in this case.
Playing around with the functions is hit-or-miss, and when that fails,
somehow the larger table saves the day.
--
John Naylor
EDB: http://www.enterprisedb.com
diff --git a/src/backend/catalog/genbki.pl b/src/backend/catalog/genbki.pl
i
if you set any of the fields after a MemSet, the values of the
> padding bytes that were set to 0 are now unspecified. It seems much
> safer to actually spell out the padding fields of a hash key.
No, the standard is telling you why you need to memset if consistency of
padding bytes matters
for this, so changing current usage will
just cause unnecessary code churn.
--
John Naylor
EDB: http://www.enterprisedb.com
On Wed, Sep 13, 2023 at 3:46 PM Junwang Zhao wrote:
>
> On Wed, Sep 13, 2023 at 4:22 PM John Naylor
> wrote:
> > - memset(part_entry, 0, sizeof(LogicalRepPartMapEntry));
> > - part_entry->partoid = partOid;
> > + Assert(part_entry->partoid == partOi
hould be faster since there is no function call, but I'm not
> 100% sure ;)
Neither has a function call. MemSet is a PG macro. You're thinking of
memset, the libc library function, but a decent compiler can easily turn
that into something else for fixed-size inputs.
--
John Naylor
EDB: http://www.enterprisedb.com
+ PG_RETURN_TEXT_P(cstring_to_text_with_len(targetpath, rllen));
This could be a worthwhile cosmetic improvement if the nul-terminator (and
space reserved for it, and comment explaining that) is taken out as well,
but the patch didn't bother to do that.
--
John Naylor
EDB: http://www.enterprisedb.com
bit multiplication?
--
John Naylor
EDB: http://www.enterprisedb.com
owers-of-two for X before the primes works most
of the time with our inputs, even for some unicode normalization functions,
on the first seed iteration. That likely won't make any difference in
practice, but it's an interesting demo. I've attached these two draft ideas
as text.
--
John Nayl
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
I didn't see any recent mentions in the archives, so I'll volunteer to
be CF manager for 2023-11.
On Thu, Nov 2, 2023 at 4:35 PM Daniel Gustafsson wrote:
>
> > On 1 Nov 2023, at 07:33, John Naylor wrote:
> >
> > I didn't see any recent mentions in the archives, so I'll volunteer to
> > be CF manager for 2023-11.
>
> You probably need some extra admin privile
has some
momentum and needs a little push.
If you have submitted a patch this cycle and have not yet reviewed a
patch, we encourage you to sign up to do so. If you actively
reviewing, we are grateful! We perennially have plenty of code, but a
shortage of good review.
--
John Naylor
On Wed, Nov 1, 2023 at 9:18 AM Chapman Flack wrote:
> So, it would not have been my choice to assign RfC status before getting to a
> resolution on that.
It's up to the reviewer (here Chapman), not the author, to decide
whether to set it to RfC. I've set the status to "needs review".
On Sat, Oct 28, 2023 at 4:15 AM Jeff Davis wrote:
>
> I plan to commit something like v3 early next week unless someone else
> has additional comments or I missed a concern.
Hi Jeff, is the CF entry titled "Unicode character general category
functions" ready to be marked committed?
lel CREATE INDEX for BRIN indexes
Direct SSL Connections
BRIN - SK_SEARCHARRAY and scan key preprocessing
ltree hash functions
pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH
--
John Naylor
On Tue, Oct 17, 2023 at 9:39 PM Robert Haas wrote:
>
> Cool. Seems we are all in agreement, so committed these. Thanks!
Thank you for getting this across the finish line!
On Fri, Oct 13, 2023 at 10:07 AM Nathan Bossart
wrote:
>
> On Thu, Sep 14, 2023 at 04:28:26PM +0800, Junwang Zhao wrote:
> > Add a v2 with some change to fix warnings about unused-parameter.
> >
> > I will add this to Commit Fest.
>
> This looks reasonable to me. I've marked the commitfest entry
On Wed, Oct 25, 2023 at 12:21 PM Tom Lane wrote:
>
> John Naylor writes:
> > I'd prefer just adding "Assert(hentry->event == oldn);" and declaring
> > hentry PG_USED_FOR_ASSERTS_ONLY.
>
> I'm not aware of any other places where we have Asserts checking
>
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 a
On Mon, Jul 3, 2023 at 5:15 PM David Rowley wrote:
>
> On Fri, 30 Jun 2023 at 18:45, John Naylor
wrote:
> I looked over your patch and don't see anything to report aside from
> the unfinished/undecided part around the tiebreak function for
> tuplesort_begin_index_hash().
I went
d (which has a CF entry), and overall I
don't find the changes to be an improvement. (It wouldn't hurt to link to
the TOAST section, though.)
--
John Naylor
EDB: http://www.enterprisedb.com
though the patch claims not to support anything but a power of two. It's
tiny enough to declare it inline so the compiler can specialize for each
call site.
+{ oid => '5101', descr => 'convert int4 number to binary',
Needs to be over 8000.
--
John Naylor
EDB: http://www.enterprisedb.com
On Wed, Aug 16, 2023 at 9:24 PM Nathan Bossart
wrote:
>
> On Wed, Aug 16, 2023 at 10:35:27AM +0700, John Naylor wrote:
> > Now I'm struggling to understand why each and every instance has its own
> > nominal buffer, passed down to the implementation. All we care about
On Thu, Aug 17, 2023 at 10:26 PM Nathan Bossart
wrote:
>
> On Thu, Aug 17, 2023 at 12:35:54PM +0700, John Naylor wrote:
> > That makes it a lexically-scoped global variable, which we don't need
> > either. Can we have the internal function allocate on the stack, then
> &
ets.off)::int2[])
+SELECT row_number() over(order by blk), tidstore_set_block_offsets(blk,
array_agg(offsets.off)::int2[])
row_number | tidstore_set_block_offsets
+
1 |
2 |
3 |
4 |
5 |
(5 rows)
o much memory in general.
Maybe using the full uint64 is too much.
> On Mon, Aug 14, 2023 at 8:05 PM John Naylor
> wrote:
> > This is possibly faster than v38-0010, but looking like not worth the
complexity, assuming the other way avoids the bug going forward.
>
> I prefer 0010
On Wed, Aug 16, 2023 at 12:17 AM Nathan Bossart
wrote:
>
> On Tue, Aug 15, 2023 at 01:53:25PM +0700, John Naylor wrote:
> > - *ptr = '\0';
> > + Assert(base == 2 || base == 8 || base == 16);
> >
> > + *ptr = '\0';
> >
> > Spurious whitespace chan
This is something I coded up to get to an API more similar to one in
simplehash, as used in tidbitmap.c. It seem worth doing on its own to
reduce code duplication, and also simplifies coding of varlen types and
"runtime-embeddable values".
--
John Naylor
EDB: http://www.enterprisedb.com
v38-ART.tar.gz
Description: application/gzip
mpiler quiet */
actual_arg_types[0] = InvalidOid;
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Aug 22, 2023 at 3:10 AM Dean Rasheed
wrote:
>
> OK, cool. This looks good to me.
LGTM too.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Apr 22, 2022 at 11:13 AM David Rowley wrote:
>
> On Thu, 21 Apr 2022 at 19:09, John Naylor
> wrote:
> > I intend to commit David's v2 fix next week, unless there are
> > objections, or unless he beats me to it.
>
> I wasn't sure if you wanted to handle
I intend to commit David's v2 fix next week, unless there are
objections, or unless he beats me to it.
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Apr 19, 2022 at 12:30 PM David Rowley wrote:
>
> Thanks for looking at this.
>
> On Tue, 19 Apr 2022 at 02:11, John Naylor
> wrote:
> > IIUC, this function is called by tuplesort_begin_common, which in turn
> > is called by tuplesort_begin_{heap, indexe
bit less noisy".
--
John Naylor
EDB: http://www.enterprisedb.com
use a
serious loss of performance in the resulting scanner. If you give the
flag twice, you will also get comments regarding features that lead to
minor performance losses."
--
John Naylor
EDB: http://www.enterprisedb.com
Hi Bruce,
"Improve validation of ASCII and UTF-8 text by processing 16 bytes at
a time (John Naylor)"
The reader might assume here that ASCII is optimized regardless of
encoding, but it is only optimized in the context of UTF-8. So I would
just mention UTF-8.
Thanks!
--
John Naylor
I wrote:
> I agree this is only useful in development. Removal sounds fine to me,
> so I'll do that soon.
This is done.
--
John Naylor
EDB: http://www.enterprisedb.com
en to remove them someday (i.e.
"deprecated"), but we are not going to improve them in any meaningful
way, and users would be warned about using them in new projects if
better alternatives are available.
--
John Naylor
EDB: http://www.enterprisedb.com
tuples. It also shows a 20% regression for 32MB
workmem and 64 byte tuples.
I don't have anything to add to the discussion about whether something
needs to be done here for PG15. If anything, changing work_mem is an
easy to understand (although sometimes not practical) workaround.
--
John Naylor
EDB
On Mon, May 16, 2022 at 9:18 PM Bruce Momjian wrote:
>
> Newer wording:
>
> Improve validation of UTF-8 text (even if only ASCII) by processing
> 16 bytes at a time (John Naylor)
Thanks! I also think Heikki should be mentioned as a coauthor here --
the ASCII codi
together, or failing that, downgrade to DEBUG5 or so.
I agree this is only useful in development. Removal sounds fine to me,
so I'll do that soon.
--
John Naylor
EDB: http://www.enterprisedb.com
latest tests, then use that as a starting point to test
thresholds with dual-pivot.
--
John Naylor
EDB: http://www.enterprisedb.com
From 5e920d9d3e8d2a2a75e63ade8bc73c8322c1934b Mon Sep 17 00:00:00 2001
From: John Naylor
Date: Mon, 30 May 2022 10:09:17 +0700
Subject: [PATCH v1 1/2] Create internal wo
rt-term
fix, and my reading of the thread is that the other proposals are too
invasive at this point in the cycle. Both of them have a draft patch
in the thread. #2, i.e. wasting MAXALIGN of space, seems the simplest
and most localized. Any thoughts on pulling the trigger on either of
these two appro
its of item offset || blockhi || blocklo
A concern here is most tids won't use many bits in blockhi either,
most often far fewer, so this would make the tree higher, I think.
Each value of blockhi represents 0.5GB of heap (32TB max). Even with
very large tables I'm guessing most pages of interest to vacuum are
concentrated in a few of these 0.5GB "segments".
And it's possible path compression would change the tradeoffs here.
--
John Naylor
EDB: http://www.enterprisedb.com
ode can
either store a pointer or a value." But without the advantage of
variable length keys).
--
John Naylor
EDB: http://www.enterprisedb.com
I've pushed 0001 (although the email seems to have been swallowed
again), and pending additional comments on 0002 and 0003 I'll squash
and push those next week. 0004 needs some thought on integrating with
symbols we discover during configure.
--
John Naylor
EDB: http://www.enterprisedb.com
to you off-list, I have some thoughts on the nodes using SIMD:
> On Thu, Jun 16, 2022 at 4:30 PM John Naylor
> wrote:
> >
> > For now, though, I'd like to question
> > why we even need to use 32-byte registers in the first place. For one,
> > the paper referenced has 16-
On Fri, Jul 8, 2022 at 3:06 PM John Naylor wrote:
>
> I've pushed 0001 (although the email seems to have been swallowed
> again), and pending additional comments on 0002 and 0003 I'll squash
> and push those next week.
This is done.
> 0004 needs some thought on integrating wi
e too (if I understand your claim
correctly). I'm not quite convinced of that in this case.
> I would definitely test before assuming binary search is better.
I wasn't very clear in my language, but I did reject binary search as
having bad branch prediction.
--
John Naylor
EDB: http://www.enterprisedb.com
I wrote:
> We can also shave a
> few percent by having pg_utf8_verifystr use SSE2 for the ascii path. I
> can look into this.
Here's a patch for that. If the input is mostly ascii, I'd expect that
part of the flame graph to shrink by 40-50% and give a small boost
overall.
--
John N
choice of node types might not be
terribly important for these two cases. That's good if that's true in
general -- a future performance-critical use of this code might tweak
things for itself without upsetting vacuum.
--
John Naylor
EDB: http://www.enterprisedb.com
VECTOR_WIDTH
I wonder if we'd lose a bit of efficiency here by not accumulating set bits
from the three conditions, but it's worth trying.
--
John Naylor
EDB: http://www.enterprisedb.com
ult project to be smart about memory -- step one might be
to invent a scheduler. (The autovacuum launcher and checkpointer, etc have
their own logic about when to do things, but while running they too are
just OS processes scheduled by the kernel.)
--
John Naylor
EDB: http://www.enterprisedb.com
_string() to be inlined, with a constant parameter deciding whether
> ->strval is expected. That'd likely be enough to get the compiler specialize
> the code for us.
I had a look at this but it's a bit more invasive than I want to
devote time to at this point.
--
John Naylor
EDB: http://
so only backslash will go back to the top.
Both the above changes are split into a new 0003 patch for easier
review, but in the end will likely be squashed with 0002.
--
John Naylor
EDB: http://www.enterprisedb.com
From 3d8b39ff1c1a4abf9effc45323b293b62551770a Mon Sep 17 00:00:00 2001
From: John N
On Thu, Jul 7, 2022 at 3:16 AM David Rowley wrote:
>
> Pushed.
Hmm, the commit appeared on git.postgresql.org, but apparently not in
my email nor the list archives.
--
John Naylor
EDB: http://www.enterprisedb.com
lus the ending double-quote). We can also shave a
few percent by having pg_utf8_verifystr use SSE2 for the ascii path. I
can look into this.
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Jun 23, 2022 at 9:17 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-06-03 13:28:16 +0700, John Naylor wrote:
> > 1. That would require putting the name physically closer to the end of
> > the column list. To make this less annoying for users, we'd need to
> >
s and timsort for objects. I
wasn't sure if dual pivot was not good for objects (which could have
possibly-complex comparators) or if timsort was just simply good for
Java's use cases. It seems accessible to try doing, so I'll look into
that.
--
John Naylor
EDB: http://www.enterprisedb.com
f anyone
> happened to hit this case and find the performance regression
> unacceptable then they have a way out... increase work_mem a little.
Since #4 is such a small lift, I'd be comfortable with closing the open item.
--
John Naylor
EDB: http://www.enterprisedb.com
er reasons. Is Matthias's patch or
something like it a good next step?
--
John Naylor
EDB: http://www.enterprisedb.com
tages of review, we want to document design
decisions so it's more clear for the reader.
--
John Naylor
EDB: http://www.enterprisedb.com
way, in this thread
https://www.postgresql.org/message-id/CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com
where you may find this patch
https://www.postgresql.org/message-id/attachment/120560/0007-Specialize-pagetable-sort-routines-in-tidbitmap.c.patch
and see if it helps.
--
J
example.
These two aspects would also bring it closer to Andres' prototype, which 1)
makes review easier and 2) easier to preserve optimization work already
done, so +1 from me.
--
John Naylor
EDB: http://www.enterprisedb.com
think it's way too much to ask for the first use case.
--
John Naylor
EDB: http://www.enterprisedb.com
Hm. Wouldn't it make sense to just use the normal tuple deforming
routines and
> then map the results to the structs?
I wasn't sure if they'd be suitable for this, but if they are, that'd make
this easier and more maintainable. I'll look into it.
--
John Naylor
EDB: http://www.enterprisedb.com
lper functions/macros similar to the above but
instead of passing a tuple descriptor, use info we have at compile time.
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Jul 19, 2022 at 10:57 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-07-19 14:30:34 +0700, John Naylor wrote:
> > I'm thinking where the first few attributes are fixed length, not null,
and
> > (because of AIX) not double-aligned, we can do a single memcpy on
mult
me library)
there is no FREE cursor_name statement in ECPG.
This is because in ECPG,
DECLARE CURSOR doesn't translate to a function
call into
I've pushed that in addition to your changes, thanks!
--
John Naylor
EDB: http://www.enterprisedb.com
e of time to get tied up about the fine details of
something that will not likely happen for several years at the
earliest.
--
John Naylor
EDB: http://www.enterprisedb.com
an extra field to track the role OID in one of the GUC
> structs or in one of its API arguments, that's fine by me.
>
> If this requires more work, a revert can of course be discussed, but I
> am not getting that this is really necessary here. This would be the
> last option to consider
resql.org/message-id/1178821226.6034.63.camel@goldbach
Did we already have a hash lookup for IN clauses with constants and the
above commit adds NOT IN? If so, maybe we have enough to remove this todo
item.
--
John Naylor
EDB: http://www.enterprisedb.com
he chance of different
patches conflicting with each other. It doesn't really matter what the oid
here is, since at feature freeze a committer will change them anyway.
--
John Naylor
EDB: http://www.enterprisedb.com
and I
just forgot to consider that.
--
John Naylor
EDB: http://www.enterprisedb.com
erence, but in any case I
don't see a slowdown anywhere.
[1]
https://www.postgresql.org/message-id/CAFBsxsHeTACMP1JVQ%2Bm35-v2NkmEqsJMHLhEfWk4sTB5aw_jkQ%40mail.gmail.com
--
John Naylor
EDB: http://www.enterprisedb.com
master-vs-custom-ext-v2.ods
Description: application/vnd.oasis.opendocument.spreadsheet
On Thu, Jul 21, 2022 at 11:22 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 21 Jul 2022 10:20:30 +0700, John Naylor <
john.nay...@enterprisedb.com> wrote in
> > On Wed, Jul 20, 2022 at 3:40 PM Kyotaro Horiguchi <
horikyota@gmail.com>
> > wrote:
> > > By the w
On Thu, Apr 28, 2022 at 7:27 AM Euler Taveira wrote:
>
> Hi,
>
> While reading worker.c, I noticed that the referred SQL command was wrong.
> ALTER SUBSCRIPTION ... REFRESH PUBLICATION instead of ALTER TABLE ... REFRESH
> PUBLICATION. Trivial fix attached.
Pushed, thanks!
ink they heard: "okay, so run a full vacuum". I
would prefer these misunderstandings to get a big fat syntax error if
they are carried out.
--
John Naylor
EDB: http://www.enterprisedb.com
* tie-breaker comparisons may be required. Typically, the optimization
* is only of value to pass-by-value types anyway, whereas abbreviated
* keys are typically only of value to pass-by-reference types.
*/
I can take a stab at this, unless you had something else in mind.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Apr 18, 2022 at 6:54 PM 汪洋 wrote:
>
> subscribe pgsql-hackers
Hi, this mailing list is not managed by subject line. To subscribe, please visit
https://lists.postgresql.org/
--
John Naylor
EDB: http://www.enterprisedb.com
scuss: deletion, API design, SIMD support, more tests etc.
+1
(FWIW, I think the current thread is still fine.)
--
John Naylor
EDB: http://www.enterprisedb.com
ignal
> procsignal sinvaladt logtape rangetypes
I was talking only about catalog/pg_*.c functions, as in Japin Li's latest
patch. You didn't mention whether your examples fall in the category Tom
mentioned upthread, so I'm not sure what your angle is.
--
John Naylor
EDB: http://www.enterprisedb.com
On Mon, Aug 1, 2022 at 9:16 PM Tom Lane wrote:
>
> John Naylor writes:
> > You are correct, but I wonder if it'd be better to just drop the comment
> > entirely. I checked a couple other random headers with function
> > declarations and they didn't have such a comment,
epends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
--
John Naylor
EDB: http://www.enterprisedb.com
space, as is customary? The rest LGTM.
--
John Naylor
EDB: http://www.enterprisedb.com
sary, but it was sufficient and already present, so I borrowed
it for the PoC.
--
John Naylor
EDB: http://www.enterprisedb.com
other files, and would be the place to put helper
functions. Thoughts?
[1] https://docs.microsoft.com/en-us/archive/blogs/reiley/macro-revisited
[2]
https://stackoverflow.com/questions/56049110/including-the-correct-intrinsic-header
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Aug 25, 2022 at 1:01 AM Nathan Bossart wrote:
>
> On Wed, Aug 24, 2022 at 11:07:03AM +0700, John Naylor wrote:
> > The important thing is: if we compile with __aarch64__ as a target:
> > - Will the compiler emit the intended instructions from the intrinsics
> > wit
--
John Naylor
EDB: http://www.enterprisedb.com
diff --git a/src/common/wchar.c b/src/common/wchar.c
index 1e6e198bf2..1ca7533f00 100644
--- a/src/common/wchar.c
+++ b/src/common/wchar.c
@@ -1918,11 +1918,12 @@ pg_utf8_verifystr(const unsigned char *s, int len)
const int orig_len = len;
uint32 state
On Wed, Aug 24, 2022 at 11:56 PM Nathan Bossart
wrote:
>
> On Wed, Aug 24, 2022 at 11:59:25AM +0700, John Naylor wrote:
> > It seems "scalar" would be a bad choice since it already means
> > (confusingly) operating on the least significant element of a vecto
701 - 800 of 1330 matches
Mail list logo
