ent. Do you have any
> proposal about the code?
>
Perhaps the way to do it is to make ChangeVarNodesExtended() take a
callback function to be invoked for each node visited. The callback
(which would then be in the planner, with the other SJE code) would do
any special handling it needed (for RangeTblRef and RestrictInfo
nodes), and call ChangeVarNodes_walker() for any other types of node,
to get the default behaviour.
Regards,
Dean
uot; also needs updating. There may be more places. I'd
suggest a bit of grepping in the docs (and probably also in the code)
for other places that need updating.
It also feels like this needs more regression tests, plus some new
isolation test cases.
Regards,
Dean
From ea50933617ec2fd42ffe192
coverage.
So patch 0001, attached, adds a new set of regression tests, near the
start of rowsecurity.sql, which specifically tests which policies are
applied for each command variant.
Patch 0002 updates the doc table to try to be clearer and more
accurate, and consistent with the test results f
can also indicate a pole error (e.g.,
> input 0 or a negative integer), not just overflow.
OK, thanks. I've updated that comment and committed it.
Regards,
Dean
DRF is to allow per-subscriber variations in change broadcasts,
enabling granular control over what data is sent to each subscriber based
on their session context.
Best,
Dean S
On Mon, Mar 17, 2025 at 4:32 AM Amit Kapila wrote:
> On Sun, Mar 16, 2025 at 12:59 AM Dean wrote:
> &g
replica filtering allows for session-specific, per-row, and
per-column filtering - features currently not supported by existing
replication filters, enhancing security and data privacy.
I look forward to hearing your thoughts!
Best,
Dean S
at way, the count always matches the number of rows returned
when there's a RETURNING clause, which I think is true of all other
DML commands.
Regards,
Dean
king along the same lines. This particular issue feels
a bit manufactured, and unlikely to occur in practice, but I'm happy
to go with whatever you decide.
Thanks for taking care of this.
Regards,
Dean
ss if that branch is
removed), but as a comment higher up says, that would be more
expensive. So perhaps this new comment should say "This is why it's
preferable to handle simple PHVs in the branch above, rather than this
branch."
Finally, ReplaceWrapOption should be added to pgindent's typedefs.list.
Regards,
Dean
On Sat, 1 Mar 2025 at 11:30, Dean Rasheed wrote:
>
> With those updates, I think this is ready for commit, which I'll do in
> a day or two, if there are no further comments.
>
Committed.
Regards,
Dean
he code shown
> above unnecessary, and we can simply remove it.
>
Yes, that makes sense, and it seems like a fairly straightforward
simplification, given that perform_pullup_replace_vars() sets it back
to false shortly afterwards.
The same thing happens in pull_up_constant_function().
Regards,
Dean
On Thu, 14 Nov 2024 at 22:35, Dean Rasheed wrote:
>
> On Thu, 14 Nov 2024 at 16:28, Dmitry Koval wrote:
> >
> > >SELECT gamma(float8 '1e-320');
> > ERROR: value out of range: overflow
> >
> > >SELECT gamma(float8 '0');
> >
aviour more
obvious.
* I also tweaked the regression tests a bit, and copied the existing
test style which displays both the expected and actual results from
each test.
With those updates, I think this is ready for commit, which I'll do in
a day or two, if there are no further comments.
Re
On Mon, 24 Feb 2025 at 09:21, Richard Guo wrote:
>
> Here are the updated patches with revised comments and some tweaks to
> the commit messages. I plan to push them in one or two days.
>
LGTM.
Regards,
Dean
from
a small runtime performance hit.
Given that we're moving this part of expanding virtual generated
columns to the planner, I wonder if we should also move the other bits
(build_generation_expression and expand_generated_columns_in_expr)
too, so that they're all together. That could be a follow-on patc
On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
>
> One thing I don't like about this is that it's introducing more code
> duplication between pullup_replace_vars() and
> ReplaceVarsFromTargetList(). Those already had a lot of code in common
> before RETURNING OLD/N
VarsFromTargetList(). Those already had a lot of code in common
before RETURNING OLD/NEW was added, and this is duplicating even more
code. I think it'd be better to refactor so that they share common
code, since it has become quite complex, and it would be better to
have just one place
imitation to have. It would be
nice to have this fully working for the next release.
Attached is a rough patch that moves the expansion of virtual
generated columns to the planner. It needs a lot more testing (and
some regression tests), but it does seem to fix all the issues
mentioned in this thr
scribe output (and maybe also pg_dump) to explicitly output
"virtual" for columns of this kind. I know that that's the default for
generated columns, but someone reading the output might not know or
remember that, so perhaps it would be helpful to be explicit.
Regards,
Dean
d with CMD_INSERT.
I'm not sure if that represents an actual bug, but it looks wrong. It
should perhaps be called "ri_extraUpdatedCols_valid", and only set to
true when ExecInitGenerated() is called with CMD_UPDATE, and
ri_extraUpdatedCols is populated.
Regards,
Dean
nteger to a bytea
produces 2, 4, or 8 bytes, depending on the width of the integer type.
The result is the two's complement representation of the integer, with
the most significant byte first.", and then list the examples to
demonstrate that.
Regards,
Dean
be consistent with the idea that these are being regarded
primarily as bytea operations, rather than integer operations (just as
the bit <-> integer casts are documented in 9.6 "Bit String Functions
and Operators").
Regards,
Dean
nks. I hadn't tested qualified table names in the RETURNING list.
I've pushed a fix for that.
Regards,
Dean
On Wed, 8 Jan 2025 at 09:38, Dean Rasheed wrote:
>
> OK, done.
>
> I also noticed that I had failed to use quote_identifier() in
> ruleutils.c for the new WITH aliases, so I've fixed that and adjusted
> a couple of the test cases to test that.
>
I went over this again
t
in first, but the one that comes second will need to do something like
this.
Regards,
Dean
[1] https://commitfest.postgresql.org/51/4723/
virt-gen-cols-with-returning-old-new.patch.no-cfbot
Description: Binary data
On Thu, 9 Jan 2025 at 03:18, Greg Sabino Mullane wrote:
>
> On Wed, Jan 8, 2025 at 8:44 AM Dean Rasheed wrote:
>>
>> Attached is a more complete patch
>
> +1, looks good
>
Thanks for looking. I've pushed this now.
(I realised that I had missed \lo_list, so I a
ith a question mark,
because all other boolean columns in psql meta-commands end with a
question mark.
Regards,
Dean
xactly the same; the ending "?" matches
> things like "Key?" in \d of an index or the "Default?" column in \dc.
> It's a boolean, so people know how to read it.
>
By the time the filler words have been stripped out, the description
isn't really adding any useful information that can't be guessed from
the parameter name and value. So I tend to agree that it should be
left out (for now at least).
Regards,
Dean
y don't say what the range of
the type is. For example, we currently do:
select repeat('1', 50)::bit(50)::int;
ERROR: integer out of range
Regards,
Dean
"integer out of range" and "bigint out of
range" would be more consistent with existing error messages.
Regards,
Dean
ceVarsFromTargetList()) needs that when expanding whole-row
variables. Here's a simple reproducer which crashes:
CREATE TABLE foo (a int, b int GENERATED ALWAYS AS (a*2) VIRTUAL);
ALTER TABLE foo ADD CONSTRAINT foo_check CHECK (foo IS NOT NULL);
Regards,
Dean
do it that way round by default -- i.e., make it like
\dconfig and have 2 columns, "Parameter" and "Value", with lots of
rows.
Perhaps it could also have a "Description" column, which might help
with things like distinguishing between authenticated user and session
user.
Regards,
Dean
t and be fine.
>
Ah yes, I see. Thanks for that. It looks like the differences in
xml_2.out were for a specific change in libxml2 behaviour that only
affects error details in a small number of cases, so cloning the diffs
looks like it should be fine in this case.
Regards,
Dean
similar code that does quote variable names
properly).
I scanned the rest of ruleutils.c, and didn't find any other issues.
Regards,
Dean
From 868ea003a54adeeae470407321fe4481c95dfccb Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Sat, 11 Jan 2025 11:08:50 +
Subject: [PATCH v1 1/2
te_columns_pre_96[] needs to
be updated to support connecting to pre-9.6 servers.
The translate_columns entries for this new column should be true, so
that the "yes"/"no" gets appropriately translated. That means that
describeOperators() will need a similar translate_columns array.
Regards,
Dean
, '1234567890123456');
> \c - bar
> select * from t1; -- permission denied
> select id, ccredacted from t1; -- ok
Makes sense.
Regards,
Dean
in more detail. So in the end, I decided
to just add a sentence to each command's description, keeping it as
short as possible.
Regards,
Dean
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index 72f3347..c48bcfb
--- a/doc/src/sgml/ref/psql-re
as had a decent amount of testing and review, so yes, I do plan to
commit it for v18.
In fact I think it is probably best to commit it soon, so that it has
more time in tree, ahead of v18. With that in mind, I plan to go over
it again in detail, and barring any other review comments, commit it.
Regards,
Dean
#x27;t looked at yet, but they should be easy to make work in the
same way, if people think this is useful.
Regards,
Dean
[1]
https://www.postgresql.org/message-id/flat/20240701220817.483f9b645b95611f8b1f6...@sranhm.sraoss.co.jp
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/ps
On Sat, 30 Nov 2024 at 00:38, tsinghualucky...@foxmail.com
wrote:
>
> Dear Dean Rasheed, I have reviewed the v4 patch and it is very thoughtful and
> reasonable, with a very clever attention to detail (plus I am very happy that
> we can get rid of the goto, which I was not
On Fri, 29 Nov 2024 at 13:10, Dean Rasheed wrote:
>
> There are a couple more things that I think need tidying up. I'll post an
> update when I get back to my computer.
>
Here's an update with some cosmetic tidying up, plus a couple of
not-so-cosmetic changes:
The new
cases. Here is the patch of version v3.
>
> It looks fine to me. The only things I'd adjust are stylistic,
> namely; 1) remove two tabs before the goto label, 2) remove redundant
> braces around the goto cleanup, 3) rename the variable "q" to
> something slightly more
amp;parsetree->hasRowSecurity);
rather than having a separate second step to update the flag on
"parsetree", and similarly for fireRIRrules()'s recursive calls to
itself. If, in the future, it becomes necessary to invoke
fireRIRrules() on more parts of a Query, it's then much more likely
that the new code won't forget to update the parent query's flag.
Regards,
Dean
be possible to write this using a
single additional allocated NumericVar and one init_var()/free_var()
pair.
There's no need to use floor(), since the div_var() call already
produces a floored integer result.
It could use some regression test cases.
Regards,
Dean
On Tue, 29 Oct 2024 at 13:05, Dean Rasheed wrote:
>
> Rebased version attached. No other changes.
>
In the light of 7f798aca1d5df290aafad41180baea0ae311b4ee, I guess I
should remove various (void *) casts that this patch adds, copied from
old code. I'll wait a while though, ju
ke a decision, and then standardise
> > on whatever people decide.
>
> I am not a native English speaker, but if this is natural spelling in
> English, I wonder we can replace all of them to leakproof without a hyphen.
>
Yes, I think we should do that (in a separate patch).
Regards,
Dean
the most useful thing to do
from a practical point of view, and if we do that for too-large
inputs, it makes sense to do the same for too-close-to-zero inputs.
OTOH, gamma(+/-0) = +/-Infinity is right from a mathematical point of
view, and consistent with the POSIX spec, and it's also consistent
with the functions cot() and cotd().
Regards,
Dean
RelationDesc,
PRS2_NEW_VARNO);
Regards,
Dean
I originally had in mind was doing it at the end of the RLS
policy loop, rather than adding another loop, as in the attached delta
patch. This passes all the current tests, and appears to work fine in
the new tests with RLS policies referring to virtual generated
columns.
Regards,
Dean
rls-fi
-bounds, like array_fill(). I.e., something like:
random_array(min int, max int, dims int[] [, lbounds int[]]) -> int[]
Returns an array filled with random values in the range min <= x <= max,
having dimensions of the lengths specified by dims. The optional lbounds
argument supplies lower-bound values for each dimension (which default
to all 1).
Regards,
Dean
tes random values, more
similar to the random(min, max) functions. Also I think it's more
useful if it shares the same PRNG, controlled by setseed(), and it
makes sense to group all such functions together.
Regards,
Dean
{{1,2},{3,4},{10,20}}
Regards,
Dean
ments so
far though, so I think we should make a decision, and then standardise
on whatever people decide.
Regards,
Dean
ter fixing that, I think it's sufficient to just list one
usage example.
Regards,
Dean
From 2a14be071dd2e721e768fdbaa57b096d509773aa Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Wed, 30 Oct 2024 08:41:41 +
Subject: [PATCH v3] tablefunc: Add rand_array() functions.
These functions
;t
look like those patches were committed, and there are still many such
warnings, if you try compiling postgres with those flags.
[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKGJ7EQm9extQAgrFZNNUKqRT8Vv5t1tKqA-5nEcYn0%2BwNA%40mail.gmail.com
I don't know if anyone has any plans to pick up that work again, but
in any case, it seems wise to not add more.
Regards,
Dean
https://www.postgresql.org/docs/current/tablefunc.html
They really should have their own subsection, along the same lines as
"F.41.1.1. Normal_rand", explaining what the functions do, what their
arguments mean, and giving a couple of usage examples.
Regards,
Dean
ersed. For example,
imagine you wanted to use raw_expression_tree_walker() to print out
the whole structure of a raw parse tree. You'd want your printing
callback to be called for every node, including the ReturningOption
nodes.
Regards,
Dean
On Sun, 25 Aug 2024 at 10:33, Joel Jacobson wrote:
>
> Nice. LGTM.
> I've successfully tested the new patch again on both Intel and AMD.
>
> I've marked it as Ready for Committer.
>
[Finally getting back to this]
Thanks for the review and testing.
Committed.
Regards,
Dean
On Fri, 6 Sept 2024 at 10:42, Dean Rasheed wrote:
>
> ... assuming that tgamma() and lgamma() behave according to spec ...
Nope, that was too much to hope for. Let's see if this fares any better.
Regards,
Dean
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file
hould be finite, but is too large to be
represented in a double.
In particular, this means that zero and negative integer inputs are
not genuine overflows, but should return NaN or +/-Inf, as described
in the POSIX spec.
Doing that, and assuming that tgamma() and lgamma() behave according
to spec,
x27;m reading that lgamma() in the C library is not necessarily
> thread-safe. Is that a possible problem?
It's not quite clear what to do about that. Some platforms may define
the lgamma_r() function, but not all. Do we have a standard pattern
for dealing with functions for which there is
On Wed, 4 Sept 2024 at 09:40, Peter Eisentraut wrote:
>
> On 21.08.24 12:51, Dean Rasheed wrote:
> >>
> > Well what I was thinking was that (in fireRIRrules()'s final loop over
> > relations in the rtable), if the relation had any virtual generated
> > column
On Tue, 3 Sept 2024 at 21:31, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Ah, OK. I've pushed a fix.
>
> There is an open CF entry pointing at this thread [1].
> Shouldn't it be marked committed now?
>
Oops, yes I missed that CF entry. I've closed it now
datable_views.sql?
> Do we need to add some tests?
>
I don't think so, because varreturningtype doesn't affect any
permissions checks.
> Other than that, I didn't find any issue.
Thanks for reviewing.
If there are no other issues, I think this is probably ready for commit.
Regards,
Dean
On Sat, 24 Aug 2024 at 19:17, Tom Lane wrote:
>
> About a dozen buildfarm members are complaining
>
Ah, OK. I've pushed a fix.
Regards,
Dean
they seem to confirm my previous
observation that exact mode is faster than approximate mode for
var2ndigits <= 12 or so, so I've added code to do that.
I also expanded on the comments for the quotient-correction code a bit.
Regards,
Dean
From 0b5ae26beb3b7cd0c68c566f01c527e59a264386 Mon Se
On Wed, 21 Aug 2024 at 08:00, Peter Eisentraut wrote:
>
> On 08.08.24 20:22, Dean Rasheed wrote:
> > Looking at the rewriter changes, it occurred to me that it could
> > perhaps be done more simply using ReplaceVarsFromTargetList() for each
> > RTE with virtual generate
functions in some
circumstances.
When casting a numeric to an integer, the result is rounded to the
nearest integer, and NaN/Inf generate errors, so we should probably do
the same here.
Regards,
Dean
series terms when deciding on the local rscale). That
wasn't affected significantly by the patch, and it's not surprising
that you saw nothing with brute-force testing.
In any case, I'm pretty content with those results.
Regards,
Dean
-
282595
(1 row)
select * from diffs2 except select * from diffs1;
n | z | m | w | x | y | expected | numeric_mul_rscale
---+---+---+---+---+---+--+
(0 rows)
which is exactly what I was hoping to see (no cases where the patch
made it less accurate).
Regards,
Dean
test-rscale.sql
Description: application/sql
examples where the patch differs from
HEAD, but hopefully only by being more accurate, not less.
Regards,
Dean
From 6c1820257997facfe8e74fac8b574c8f683bbebc Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Thu, 18 Jul 2024 17:38:59 +0100
Subject: [PATCH v5 1/2] Extend mul_var_short() to 5 and
so it wouldn't need to worry about
CTEs and sublink subqueries. That would also make the
hasGeneratedVirtual flags unnecessary, since we'd already only be
doing the extra work for tables with virtual generated columns. That
would eliminate possible bugs caused by failing to set those flags.
Regards,
Dean
f 32-bit-specific code
that significantly complicates this function, making it harder to
maintain. Without that code, the patch becomes much simpler, which
seems like a decent justification for any performance tradeoffs on
32-bit machines that are unlikely to affect many people anyway.
Regards,
Dea
ou found [1], I think it's entirely
possible that there are people who care about 32-bit systems, which
means that we might well get complaints, if we make it slower for
them. Unfortunately, I don't have any way to test that (I doubt that
running a 32-bit executable on my x86-64 system is a realistic test).
Regards,
Dean
[1] https://postgr.es/m/0a71b43129fb447988f152941e1db...@nidsa.net
ch is much faster. With the
patch, they both generate the same SSE2 code, so the results are
pretty consistent.
Regards,
Dean
On Fri, 12 Jul 2024 at 13:34, Dean Rasheed wrote:
>
> Then I tried compiling with -m32, and unfortunately this made the
> patch slower than HEAD for small inputs:
>
> -- var1ndigits1=5, var2ndigits2=5 [-m32, SIMD disabled]
> call rate=5.052332e+06 -- HEAD
> call rate=3.88
e extensible, if we wanted it to
return more information in the future.
Instead of adding relation_has_unique_index_ext(), maybe it would be
OK to just change the signature of relation_has_unique_index_for(). It
looks like it's only called from one other place outside
analyzejoins.c. Perhaps the same is true for innerrel_is_unique_ext().
Should match_unique_clauses() be comparing mergeopfamilies or opnos to
ensure that the clauses are using the same equality operator?
Regards,
Dean
code wants to ignore RangeTblRef
nodes, but it could delegate to ChangeVarNodes() for various other
node types to avoid code duplication. At the top level, the stuff that
ChangeVarNodes() does to fields of the Query struct would be different
for SJE, I think.
Regards,
Dean
translate(substring(&primary;, 1, 1),
>
This looks like you're missing a required package. Try installing
docbook-xsl or docbook-xsl-stylesheets or something similar (the
package name varies depending on your distro).
Regards,
Dean
many rows were filtered out:
- Use pg_stat_get_tuples_returned()
- Use pg_class.reltuples
- Use the row estimates from a plain EXPLAIN
and probably more.
Given that this isn't really a security bug, I think EXPLAIN should
probably be left as-is. Otherwise, you'd have to go round closing all
those other "holes" too.
Regards,
Dean
hese new functions, but
not normal_rand(). Incidentally, that makes writing tests much simpler
-- just call setseed() first and the output will be repeatable.
Regards,
Dean
nother option would be to only use this optimisation on 64-bit
machines, though I think that would make the code pretty messy, and it
would be throwing away the gains for large inputs, which might well
outweigh the losses.
Thoughts anyone?
Regards,
Dean
[1]
https://www.postgresql.org/message-id/
y effect was to negate both inputs to div_var(), so the
signs cancel out.)
Regards,
Dean
On Tue, 9 Jul 2024 at 10:11, Dean Rasheed wrote:
>
> OK, I have committed this.
>
Before considering the other patches to optimise for larger inputs, I
think it's worth optimising the existing mul_var() code as much as
possible.
One thing I noticed while testing the earlier p
ort() because "short" is probably a better term to use in
this context (we already use it in a preceding comment). "Small" is
potentially misleading, because the numbers themselves could be
numerically very large.
Regards,
Dean
On Mon, 8 Jul 2024 at 11:08, Joel Jacobson wrote:
>
> LGTM.
>
Thanks for the review. I have pushed and back-patched this.
Regards,
Dean
On Mon, 8 Jul 2024 at 00:40, Joel Jacobson wrote:
>
> On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> > I've also tidied up a bit by replacing all instances of SHRT_MAX with
> > a new constant NUMERIC_WEIGHT_MAX, whose name more accurately
> > describes the li
27;t affect the point being made in that comment.
I'd like to treat this as a bug-fix and back-patch it, since the
current behaviour is clearly broken.
Regards,
Dean
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
new file mode 100644
index 5510a20..57386aa
--- a/s
15) c
FROM generate_series(1, 1000);
SELECT hash_array(array_agg(width_bucket(op, b1, b2, c))) FROM t;
-- Result not changed by patch
SELECT sum(width_bucket(op, b1, b2, c)) FROM t;
Time: 3658.962 ms (00:03.659) -- HEAD
Time: 3089.946 ms (00:03.090) -- with patch
Regards,
Dean
diff --git
k quite well for 5 or 6 digits,
but at some point, we'll start seeing diminishing returns, and the
code bloat won't be worth it.
Regards,
Dean
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
new file mode 100644
index 5510a20..b556861
--- a/src/backen
2 ms (00:04.750) -- v7-mul_var_small.patch
The other advantage, of course, is that it doesn't require 128-bit
integer support.
Regards,
Dean
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
new file mode 100644
index 5510a20..b9497e1
--- a/src/backend/utils/adt/numer
On Wed, 3 Jul 2024 at 21:45, Joel Jacobson wrote:
>
> > On Wed, Jul 3, 2024, at 20:57, Dean Rasheed wrote:
> >> I wouldn't expect it to ever be off by more than 1
> >
> > OK, so then the cases I found where it was off by 2 for the mul_var_int()
> > pat
r off they can be?
>
I wouldn't expect it to ever be off by more than 1, given that
MUL_GUARD_DIGITS = 2, which corresponds to 8 decimal digits, and the
number of digits in the smaller input (and hence the number of digit
products in each column) is limited to something like 16,000 NBASE
digits.
Regards,
Dean
at increasing MUL_GUARD_DIGITS won't guarantee correctly
rounded results, no matter how much you increase it by. The only way
to guarantee that the result is correctly rounded in all cases is to
compute the full result and then round, which would be a lot slower.
Regards,
Dean
In testing, it seemed to
give a decent speedup, but perhaps a little less than before. But
that's to be balanced against having more maintainable code, and also
a function that might be useful elsewhere in numeric.c.
Anyway, here are both patches for comparison. I'll stop hacking for a
whi
mited precision intended to compute the final result
reasonably accurately to a particular rscale.
Regards,
Dean
just to ensure the results are the
same as before.
> I've tried to get a different result with and without the fix,
> but I'm failing to hit the bug.
>
> Can you think of an example that should trigger the bug?
.0001 * 5000._ with rscale = 0 triggers it (returned
50004999 instead of 50005000).
Regards,
Dean
On Sun, 30 Jun 2024 at 11:22, Joel Jacobson wrote:
>
> On Sat, Jun 29, 2024, at 14:22, Dean Rasheed wrote:
>
> > But why just split it into two pieces? That will just lead
> > to a lot of unnecessary recursion for very unbalanced inputs. Instead,
> > why not split the
going to be very
hardware-dependent, and we shouldn't presume what will work best on
the user's hardware.
However, if a 1000x1000 ndigit product is known to be faster using
Karatsuba on some particular hardware (possibly nearly all hardware),
then why wouldn't it make sense to do the above as 10 invocations of
Karatsuba?
Regards,
Dean
On Tue, 2 Jul 2024 at 08:50, Joel Jacobson wrote:
>
> On Tue, Jul 2, 2024, at 00:19, Dean Rasheed wrote:
>
> > Attachments:
> > * optimize-numeric-mul_var-small-var1-arbitrary-var2.patch.txt
>
Shortly after posting that, I realised that there was a small bug. This
1 - 100 of 646 matches
Mail list logo
