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
ommitfest
title.
--
John Naylor
EDB: http://www.enterprisedb.com
v10-0001-Rewrite-pg_utf8_verifystr-for-speed.patch
Description: Binary data
v10-0002-Use-SSE-instructions-for-pg_utf8_verifystr-where.patch
Description: Binary data
o_accumulator & next_chunk
>
> in the loop and then only at the very end check for zeros in that.
That's the approach taken in the SSE4 patch, and in fact that's the logical
way to do it there. I hadn't considered doing it that way in the pure C
case, but I think it's worth trying.
--
John Naylor
EDB: http://www.enterprisedb.com
ase because we need to return how many bytes were valid. In fact, in the
SSE case, it checks the error vector at the end and then reruns with the
fallback case to count the valid bytes.
--
John Naylor
EDB: http://www.enterprisedb.com
nd newer gcc. We
can report a range of results as we proceed.)
[1]
https://www.postgresql.org/message-id/06d45421-61b8-86dd-e765-f1ce527a5...@iki.fi
--
John Naylor
EDB: http://www.enterprisedb.com
UINT64CONST(0x8080808080808080);
> if (x != UINT64CONST(0x8080808080808080))
> return 0;
That seems right, I'll try that and update the patch. (Forgot to attach
earlier anyway)
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, Jun 3, 2021 at 3:22 PM Heikki Linnakangas wrote:
>
> On 03/06/2021 22:16, Heikki Linnakangas wrote:
> > On 03/06/2021 22:10, John Naylor wrote:
> >> On Thu, Jun 3, 2021 at 3:08 PM Heikki Linnakangas >> <mailto:hlinn...@iki.fi>> wrote:
> >>
On Mon, Jun 7, 2021 at 8:24 AM Heikki Linnakangas wrote:
>
> On 03/06/2021 21:58, John Naylor wrote:
> > The microbenchmark is the same one you attached to [1], which I extended
> > with a 95% multibyte case.
>
> Could you share the exact test you're using? I&#x
ses so "from" limits didn't have an
effect in my quick test.)
[Kossmann & Stocker, 2000] Iterative dynamic programming: a new class of
query optimization algorithms. https://doi.org/10.1145/352958.352982
[Das & Haritsa, 2006] Robust Heuristics for Scalable Optimization of
Complex SQL Queries.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.549.4331&rep=rep1&type=pdf
--
John Naylor
EDB: http://www.enterprisedb.com
ascii on 64 byte blocks at a time ((c1 | c2) | (c3 | c4)) and
check only the previous block's "chunk 4" for incomplete sequences at the
end. It's a bit messier, so I haven't done it, but it's an option.
Also, if SSE is accepted into the tree, then the C fallback is on
| mixed2
-+---+---+
1030 | 644 | 102 | 1760
v12-0001:
chinese | mixed | ascii | mixed2
-+---+---+
977 | 632 | 168 | 1113
--
John Naylor
EDB: http://www.enterprisedb.com
because
> my "intuitive" understanding is that the more elaborate the planning is,
> the more errors it can make when the estimates are off.
Yeah, I'm not sure this part is very useful and seems almost like an
afterthought. In table 3, all those poor examples are "pure" greedy
algorithms and don't have iterative refinement added, so it kind of makes
sense that poor estimates would hurt them more. But they don't compare
those with *just* a refinement step added. I also don't know how realistic
their "estimate fuzzing" is.
--
John Naylor
EDB: http://www.enterprisedb.com
contrib/bloom. I think it should be
"This allows BRIN indexes...".
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Jun 15, 2021 at 12:15 PM Robert Haas wrote:
>
> On Wed, Jun 9, 2021 at 9:24 PM John Naylor
wrote:
> > 3) It actually improves the existing exhaustive search, because the
complexity of the join order problem depends on the query shape: a "chain"
shape (linear) vs.
On Wed, Jun 16, 2021 at 12:01 PM Robert Haas wrote:
>
> On Tue, Jun 15, 2021 at 2:16 PM John Naylor
> wrote:
> > > I don't quite understand the difference between the "chain" case and
> > > the "star" case. Can you show sample queries for eac
tab3.x = tab4.y
A star has a hub with join predicates to multiple spokes:
SELECT *
FROMtab1, tab2, tab3, tab4
WHERE tab1.f1 = tab2.d1 AND
tab1.f2 = tab3.d2 AND
tab1.f3 = tab4.d3
--
John Naylor
EDB: http://www.enterprisedb.com
on ndistinct.
> Anyway, count-min sketches would be a better way to estimate the part
> not covered by MCVs - we might even assume the uniform distribution for
> individual counters, because that's what we do without MCVs anyway.
When we calculate the sketch, would it make sense to exclude the MCVs that
we found? And use both sources for the estimate?
--
John Naylor
EDB: http://www.enterprisedb.com
ulakis. On the propagation of errors in the
size of join results.
https://www.csd.uoc.gr/~hy460/pdf/p268-ioannidis.pdf
--
John Naylor
EDB: http://www.enterprisedb.com
but if we have a sketch also,
we can choose one or the other based on a plan-time speed vs accuracy
tradeoff (another use for a planner effort guc). In that scenario, for
tables with many MCVs we would only use them for restriction clauses.
--
John Naylor
EDB: http://www.enterprisedb.com
? I agree plan time is one concern - but it's
> also about analyze, as we need larger sample to build a larger MCV or
> histogram (as the paper you referenced shows).
Ah, I didn't realize the theoretical limit applied to the MCVs too, but
that makes sense since they're bas
o know about join types. Might have unintended
consequences, though.
Long term, it would be great to calculate something about the distribution
of cardinality estimates, so we can model risk in the estimates.
--
John Naylor
EDB: http://www.enterprisedb.com
idIndexId 2650
>
> to this
>
> DECLARE_UNIQUE_INDEX_PKEY(pg_aggregate_fnoid_index, 2650,
> AggregateFnoidIndexId, on pg_aggregate using btree(aggfnoid oid_ops));
+1, and the patch looks good to me.
--
John Naylor
EDB: http://www.enterprisedb.com
incorporating a limited number
of cross products into the search in a safe way. Unsurprisingly,
these features add complexity, and I don't quite understand it yet, but it
might be worth evaluating in the future.
https://btw.informatik.uni-rostock.de/download/tagungsband/B2-1.pdf
--
John Naylor
EDB: http://www.enterprisedb.com
t it seems also there are fewer branches this way. I'll
come up with a test and see what happens.
--
John Naylor
EDB: http://www.enterprisedb.com
07, and it
seems the ideas in this thread have mostly been done or superseded already.
--
John Naylor
EDB: http://www.enterprisedb.com
fferent from v12, but has the nice property of
simpler code. Both are not as nice as v11 for ascii, but don't regress for
the latter's worst case. I'm leaning towards v13 for the fallback.
--
John Naylor
EDB: http://www.enterprisedb.com
v13-0001-Rewrite-pg_utf8_verifystr-for-speed.patch
Description: Binary data
of this test.
One of the points of the talk I linked to is "if doing the sensible thing
makes things worse, try something silly instead".
Anyway, I'll play around with the scripts and see if something useful pops
out.
--
John Naylor
EDB: http://www.enterprisedb.com
len)
It seems like it would be easy to have pg_utf8_verify_one in my proposed
pg_utf8.h header and replace the body of pg_utf8_verifychar with it.
--
John Naylor
EDB: http://www.enterprisedb.com
TICE: order=decreasing, threshold=32, cmp=std, test=2, time=0.960234
NOTICE: order=decreasing, threshold=32, cmp=ids, test=0, time=0.403014
NOTICE: order=decreasing, threshold=32, cmp=ids, test=1, time=0.393329
NOTICE: order=decreasing, threshold=32, cmp=ids, test=2, time=0.395659
-
uspect if we experiment on two extremes of type "heaviness" (accessing
and comparing trivial or not), such as uint32 and tuplesort, we'll have a
pretty good idea what the parameters should be, if anything different. I'll
do some testing along those lines.
(BTW, I just realized I l
On Thu, Jul 1, 2021 at 10:19 PM Thomas Munro wrote:
>
> Spotted in the "Hashing" section:
>
> "Use "lazy" hash tables to look up only the tuples that are actually
requested"
>
> David Rowley has knocked that one off. He called it Result Cache.
T
On Thu, Jul 1, 2021 at 9:23 PM Bruce Momjian wrote:
> Agreed. Please remove them or I can do it.
Done, and also changed next release to "15".
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Jul 9, 2021 at 6:30 AM Pavel Borisov wrote:
> Thank you for your review!
> I've rebased the patch and made the changes mentioned.
> PFA v5.
I've set this back to "needs review" in CF.
--
John Naylor
EDB: http://www.enterprisedb.com
es
sense to commit a refactoring that conflicts with that, while not
necessarily making life easier for that feature. Incremental view
maintenance is highly desirable, so I don't want to put up unnecessary
roadblocks.
[1] https://commitfest.postgresql.org/33/2138/
--
John Naylor
EDB: http://www.enterprisedb.com
--
alterlock2 | ShareRowExclusiveLock
(1 row)
--
John Naylor
EDB: http://www.enterprisedb.com
a Relation. So that looks like a good idea, no need to rush
> that into 14 though.
I found no external references in codesearch.debian.net. I plan to commit
this in the next couple of days unless there are objections.
--
John Naylor
EDB: http://www.enterprisedb.com
e possible review point: We
don't really need to have separate control over whether to use special
instructions for CRC and UTF-8. It should probably be just one configure
knob, but having them separate is perhaps easier to review.
--
John Naylor
EDB: http://www.enterprisedb.com
v15-0001-Rew
nd discuss: 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
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
> altogether, 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
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
we don't threaten 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
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
byte 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
problem case. If 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
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
at's nice to have for other reasons. Is Matthias's patch or
something like it a good next step?
--
John Naylor
EDB: http://www.enterprisedb.com
tor, but not the "why".
Especially in early stages of review, we want to document design
decisions so it's more clear for the reader.
--
John Naylor
EDB: http://www.enterprisedb.com
a short-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
n
HEAD using my 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] Cre
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
>
plus 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
I mentioned 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 pape
o (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.
e level
> might help me.
I think that's a sign that the 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
Or more simply:
>
> 9 bits 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
be worth forcing json_lex() and
> json_lex_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
dev
h, 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: J
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
es are
necessary. Instead, each pointer storage location in an inner node 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
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 inte
te(p, 0x20))
p += 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
7;d be a difficult 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
derlying run-time 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
on't think it's the most
productive use 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
term by having 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
> las
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
his 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
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
egression tests pass.
>
> 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
think it's way too much to ask for the first use case.
--
John Naylor
EDB: http://www.enterprisedb.com
tree, for 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
a is
varlen. Otherwise, use helper 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
5, though, and I
just forgot to consider that.
--
John Naylor
EDB: http://www.enterprisedb.com
t's a real difference, 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 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
The SSE 4.2 intrinsics check
is not necessary, but it was sufficient and already present, so I borrowed
it for the PoC.
--
John Naylor
EDB: http://www.enterprisedb.com
they didn't have such a comment, and it's kind of obvious
what they're for.
--
John Naylor
EDB: http://www.enterprisedb.com
h pmsignal
> 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
nds 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
ingle space, as is customary? The rest LGTM.
--
John Naylor
EDB: http://www.enterprisedb.com
above)
That we can include into 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
801 - 900 of 1520 matches
Mail list logo
