On Wed, 28 May 2025 at 11:37, Tender Wang wrote:
>
> Dean Rasheed 于2025年5月28日周三 18:26写道：
>>
>> Unless there are any further comments, I plan to commit it in a day or so.
>
> I don't have any other comments. It looks good for me.
>
Thanks for looking. I have committed this now.
Regards,
Dean
On Mon, 26 May 2025 at 12:50, Tender Wang wrote:
>
>> > "it is possible for the parent to be excluded from the
>> > plan and so all of the entries in the resultRelInfo array may be for
>> > different relations than rootResultRelInfo."
>> >
>> > I didn't fully understand the above sentence. Can y
644
index 619592b..536d7c0
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -2905,13 +2905,22 @@ Add ARM Neon and SVE CPU intrinsics for
-Improve the speed of multiplication (Joel Jacobson, Dean Rasheed)
+Improve the speed of numeric multiplication and division (Joel Jacobson, Dean Rasheed)
+§
+§
§
+§
On Mon, 26 May 2025 at 10:39, Tender Wang wrote:
>
> jian he 于2025年5月26日周一 17:30写道：
>>
>> + Relation rootRelation = rootRelInfo->ri_RelationDesc;
>> + Relation firstResultRel = mtstate->resultRelInfo[0].ri_RelationDesc;
>> + int firstVarno = mtstate->resultRelInfo[0].ri_RangeTableIndex;
>>
>> fir
On Mon, 26 May 2025 at 07:46, Tender Wang wrote:
>
> Hi Dean,
>
> "it is possible for the parent to be excluded from the
> plan and so all of the entries in the resultRelInfo array may be for
> different relations than rootResultRelInfo."
>
> I didn't fully understand the above sentence. Can you
ingList, but I don't think it really makes sense
to do it there. The patch intentionally only does it for a MERGE into
an inherited table when there are INSERT actions, and this also allows
the new code to be more consistent with ExecInitPartitionInfo().
Regards,
Dean
From 1d20f593cbc3f4546
On Sun, 25 May 2025 at 13:41, Dean Rasheed wrote:
>
> On Sun, 25 May 2025 at 13:06, Tender Wang wrote:
> >
> > For a partitioned table, we must pass rootResultRelInfo to ExecInsert(). I
> > added the check before calling ExecInsert()
> > If it is a partitio
On Sun, 25 May 2025 at 13:06, Tender Wang wrote:
>
> For a partitioned table, we must pass rootResultRelInfo to ExecInsert(). I
> added the check before calling ExecInsert()
> If it is a partitioned table, we continue to pass rootResultRelInfo.
> Otherwise, we pass resultRelInfo.
> Please see th
On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov wrote:
>
> On 4/4/25 09:37, Richard Guo wrote:
> > On Wed, Apr 2, 2025 at 10:26 PM Richard Guo wrote:
> > With more exposure to the changes in ChangeVarNodes(), I have some
> > more concerns. As I understand it, ChangeVarNodes() is designed to
> > upd
> > On 3/4/25 10:24 AM, Andreas Karlsson wrote:
> > Rebased the patch to add support for OLD.* and NEW.*.
>
I took a closer look at this, and I have a number of comments:
* The changes for RLS look correct. However, in
get_row_security_policies(), it's not necessary to add
WCO_RLS_UPDATE_CHECK ch
rom 0001, and fixes
the paragraph mentioned above.
Regards,
Dean
From c2c49cd10f001a5ee7a2d52083b2fcd3232fc53e Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Thu, 27 Mar 2025 14:08:09 +
Subject: [PATCH v1 1/2] New RLS tests to test policies applied by command
type.
The existing RLS tests f
On Tue, 25 Mar 2025 at 05:01, Alexandra Wang
wrote:
>
> I reviewed the patch and it looks good to me. I’ve run some tests, and
> everything works as expected.
Thanks for the careful review and testing.
> Raising an error instead of silently returning Inf for invalid inputs
> like zero, negative
> On 3/4/25 10:24 AM, Andreas Karlsson wrote:
> Rebased the patch to add support for OLD.* and NEW.*.
create table t (key int primary key, val text);
insert into t values (1, 'old');
insert into t values (1, 'new') on conflict (key) do select for update
returning old.*, new.*;
key | val | key
On Wed, 12 Mar 2025 at 07:45, Richard Guo wrote:
>
> I refined the comment in v2 and ended up with:
>
> * This analysis could be tighter: in particular, a non-strict
> * construct hidden within a lower-level PlaceHolderVar is not
> * reason to add another PHV. But for now it doe
On Mon, 10 Mar 2025 at 13:05, Richard Guo wrote:
>
> Attached are the patches.
>
This looks good to me. I did some more testing, and I wasn't able to break it.
Some minor nitpicks:
These 2 comment changes from 0002 could be made part of 0001:
1). In pull_up_simple_subquery(), removing the word
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
On Wed, 5 Mar 2025 at 09:09, Richard Guo wrote:
>
> I noticed the adjacent code that sets wrap_non_vars to true if we
> are considering an appendrel child subquery, and I doubt this is
> necessary.
>
> /*
> * If we are dealing with an appendrel member then anything that's not a
> * simple Var
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');
> >
gards,
Dean
From 5c0572a0930067f7244606384542d670cd1e4aa6 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Sat, 1 Mar 2025 10:49:24 +
Subject: [PATCH v10] Allow casting between bytea and integer types.
This allows smallint, integer, and bigint values to be cast to and
from bytea. The bytea valu
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
On Fri, 21 Feb 2025 at 06:16, Richard Guo wrote:
>
> Yeah, it's annoying that the two replace_rte_variables callbacks have
> so much code duplication. I think it's a win to make them share
> common code. What do you think about making this refactor a separate
> patch, as it doesn't seem directly
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
On Tue, 18 Feb 2025 at 13:12, Richard Guo wrote:
>
> > It seems to me that, for a relation in the rangetable that has virtual
> > generated columns, we can consider it a subquery to some extent. For
> > instance, suppose we have a query:
> >
> > select ... from ... join t on ...;
> >
> > and supp
On Fri, 14 Feb 2025 at 10:59, Peter Eisentraut wrote:
>
> On 13.02.25 14:06, jian he wrote:
> > I didn't solve the out join semantic issue.
> > i am wondering, can we do the virtual generated column expansion in
> > the rewrite stage as is,
> > and wrap the expressions in PHVs if the virtual gener
On Tue, 4 Feb 2025 at 22:36, Peter Eisentraut wrote:
>
> Yeah, this is quite contorted. I have renamed it like you suggested.
I looked over this again and I think the patch is in good shape to be committed.
One thought that occurred to me was whether it would be better for the
psql describe out
On Mon, 27 Jan 2025 at 09:59, Peter Eisentraut wrote:
>
> Here is an updated patch that integrates the above changes and also
> makes some adjustments now that the logical replication configuration
> questions are resolved. I think this is complete now.
>
In struct ResultRelInfo, the following f
On Thu, 23 Jan 2025 at 14:30, Aleksander Alekseev
wrote:
>
> Hi Peter,
>
> > These casts appear to use a particular endianness, but they don't
> > document which one, and there is no explanation anywhere why that one is
> > the right one.
>
> Right, I choose network order / big-endian. I agree tha
On Tue, 14 Jan 2025 at 13:25, Aleksander Alekseev
wrote:
>
> Thanks. I agree that the proposed error messages look nicer than the
> one I used in v6. Here is the corrected patch.
>
This should use ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE, rather than
ERRCODE_INVALID_PARAMETER_VALUE, for consistency wit
On Fri, 17 Jan 2025 at 02:24, Richard Guo wrote:
>
> It seems that adding ParseNamespaceItems for the OLD or NEW aliases
> may confuse scanNameSpaceForRelid() when searching the table namespace
> for a relation item. Since they contain the same RTE,
> scanNameSpaceForRelid() might mistakenly dete
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
On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut wrote:
>
> Here is a new patch with that fixed and also a few
> tweaks suggested by Jian.
>
I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
that I would check how it works together with this patch. The good
news is that AFAICS ev
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
On Tue, 14 Jan 2025 at 08:44, Yugo NAGATA wrote:
>
> I've attached a updated patch v4 that includes fixes on translate_columns[]
> and ranslate_columns_pre_96[].
>
This looked good to me, so I've pushed both patches.
I changed the column name to "Leakproof?" with a question mark,
because all oth
On Tue, 14 Jan 2025 at 08:51, Alvaro Herrera wrote:
>
> On 2025-Jan-14, Hunaid Sohail wrote:
>
> > I've tried the approach and attached the output. Does this look good?
>
> Hmm, I'm not sure I like the third column particularly; it's noisy to
> have on all the time. I'd leave that for \conninfo+
On Mon, 13 Jan 2025 at 19:23, Alvaro Herrera wrote:
>
> But these don't show the acceptable range. We have these that do:
>
> #: utils/adt/varbit.c:1824 utils/adt/varbit.c:1882
> #, c-format
> msgid "bit index %d out of valid range (0..%d)"
>
> #: utils/adt/varlena.c:3218 utils/adt/varlena.c:3285
On Mon, 13 Jan 2025 at 17:36, Aleksander Alekseev
wrote:
>
> Besides fixing opr_sanity test I corrected error messages:
>
> -ERROR: bytea size 3 out of valid range, 0..2
> +ERROR: bytea out of valid range, ''..'\x'
>
"smallint out of range", "integer out of range" and "bigint out of
range"
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> Here is a new patch version
In expand_generated_columns_in_expr():
+ RangeTblEntry *rte;
+
+ rte = makeNode(RangeTblEntry);
+ rte->relid = RelationGetRelid(rel);
+
+ node = expand_generated_columns_internal(node, re
On Mon, 13 Jan 2025 at 08:44, Alvaro Herrera wrote:
>
> > IMO, we should continue with v35 and add all parameters from
> > PQparameterStatus,
> > as Sami suggested. The names themselves are informative enough.
>
> IMO we need more opinions. Maybe enough other people are not as unhappy
> about the
On Sat, 11 Jan 2025 at 15:42, Tom Lane wrote:
>
> +1, but you also need to update the xml_1.out and xml_2.out files.
> IIRC, xml_1.out is what comes out without --with-libxml.
> I forget what's different about xml_2.out, but you can probably
> just clone the diff for xml.out and be fine.
>
Ah yes
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
On Wed, 4 Dec 2024 at 11:21, Yugo NAGATA wrote:
>
> > Looking through the complete list of psql meta-commands, "leakproof"
> > could plausibly be added to the output of each of the following:
> >
> > \dAo+
> > \dC+
> > \df+
> > \do+
>
> I've attached a updated patch (v3-0001) that include changes
On Wed, 8 Jan 2025 at 16:14, Peter Eisentraut wrote:
>
> One thing I could use some review on is the access control handling and
> security in general. You can create virtual generated columns that have
> their own access privileges but which can read columns that the user
> does not have access
On Mon, 30 Dec 2024 at 15:48, Greg Sabino Mullane wrote:
>
> I like this, very useful. It's a shame about the conflict with \dx (lesson
> for the future: think extra carefully about option namings!). I am impressed
> that \dx \d \d+ \d+x and even \dxx all work as one might intuit with
>
On Fri, 3 Jan 2025 at 19:39, Robert Treat wrote:
>
> This is really nice work. I was curious what you think the status of
> this patch is at this point and if you are still thinking of
> committing it for v18?
>
Thanks for looking. I think that the patch is in good shape, and it
has had a decent
The output from various psql meta-commands such as \df+ can be quite
wide, making it hard to read, and there is another patch [1] that will
make it even wider. The output is much more readable if expanded mode
is used, but it's somewhat inconvenient to keep turning that on and
off, if you don't wan
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
On Fri, 29 Nov 2024, 12:01 David Rowley, wrote:
> On Fri, 29 Nov 2024 at 18:50, songjinzhou
> wrote:
> > Hello, thank you and David Rowley for your comments.
> >
> > I have used pgindent to adjust the code format and added comments and
> missing regression test cases. Here is the patch of versio
On Thu, 21 Nov 2024 at 18:00, Nathan Bossart wrote:
>
> In light of CVE-2024-10976, which was fixed by commit cd7ab57, I'd like to
> propose a bigger change to this area of the code that aims to future-proof
> it a bit. Instead of requiring hackers to carefully cart around whether a
> query refer
On Thu, 28 Nov 2024 at 07:47, 孤傲小二~阿沐 wrote:
>
> Hello hackers, I saw a recent submission: Teach planner how to estimate rows
> for timestamp generate_series. I provide a patch for the numeric type here,
> and a simple test is as follows:
>
> I really want to know your thoughts, please give me f
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
On Fri, 15 Nov 2024 at 09:55, Yugo Nagata wrote:
>
> I'll fixed the patch to add leakproof info to \do+ results, but is it worth
> leaving this info in \dAo+ results, too?
>
I suppose that might still be useful in some contexts.
Looking through the complete list of psql meta-commands, "leakproof
On Thu, 14 Nov 2024 at 16:28, Dmitry Koval wrote:
>
> I think having gamma() and lgamma() functions in PostgreSQL would be
> useful for some users, this is asked [1].
>
Thanks for looking.
> >SELECT gamma(float8 '1e-320');
> ERROR: value out of range: overflow
>
> >SELECT gamma(float8 '0');
>
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
>
> New patch version.
In expand_generated_columns_in_expr():
+/*
+ * XXX For the benefit of triggers, make two passes, so it covers
+ * PRS2_OLD_VARNO and PRS2_NEW_VARNO.
+ */
+node = expand_generated_c
On Tue, 5 Nov 2024 at 16:17, Peter Eisentraut wrote:
>
> New patch version.
What happened with the RLS support? It looks like you moved the code
to expand virtual generated columns back to the first loop in
fireRIRrules(), which doesn't work because RLS policies might contain
references to virtua
On Tue, 5 Nov 2024 at 15:23, Aleksander Alekseev
wrote:
>
> > > =# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
> > > {5}
> > > {1, 3, 8}
> > > {7, 6}
> > > ...
> >
> > Yeah, that looks like a neater API.
> >
> > Something that bothers me somewhat is that it's completely tr
On Mon, 4 Nov 2024 at 14:46, Aleksander Alekseev
wrote:
>
> Any reason not to have an interface as simple and straightforward as
> this:
>
> =# SELECT array_random(1, 10, random(0, 3)) FROM generate_series( ... )
> {5}
> {1, 3, 8}
> {7, 6}
> ...
>
Yeah, that looks like a neater API.
Something th
On Sun, 3 Nov 2024 at 03:33, Junwang Zhao wrote:
>
> PFA v11.
>
Testing this with an array with non-default lower bounds, it fails to
preserve the array bounds, which I think it should (note:
array_reverse() and array_shuffle() do preserve the bounds):
SELECT array_reverse(a), array_shuffle(a),
> On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> I would like to propose to add a new field to psql's \dAo+ meta-command
> to show whether the underlying function of an operator is leak-proof.
>
I agree that this is useful information to have, but why add it to
\dAo+ instead of \do+? Taking the e
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
On Sat, 26 Oct 2024 at 01:51, Andy Fan wrote:
>
> > 10). In this error:
> >
> > +elog(ERROR, "unsupported type %d for rand_array function.",
> > + datatype);
> >
> > "datatype" is of type Oid, which is unsigned, and so it should use
> > "%u" not "%d". Also, as above, it should
On Thu, 29 Aug 2024 at 05:39, Andy Fan wrote:
>
> Yes, that's a valid usage. the new vesion is attached. I have changed
> the the commit entry [1] from "Waiting on Author" to "Needs review".
>
Note that this needs a rebase, following commit 4681ad4b2f.
Here are a few more review comments:
1).
On Mon, 14 Oct 2024 at 16:34, jian he wrote:
>
> typedef struct ReturningOption
> {
> NodeTagtype;
> ReturningOptionKind option; /* specified option */
> char *value;/* option's value */
> ParseLoclocation;/* token location, or -1 if unknown */
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
On Wed, 4 Sept 2024 at 19:21, Tom Lane wrote:
>
> >> I'm not sure why you are doing the testing for special values (NaN etc.)
> >> yourself when the C library function already does it. For example, if I
> >> remove the isnan(arg1) check in your dlgamma(), then it still behaves
> >> the same in al
On Fri, 23 Aug 2024 at 13:40, Peter Eisentraut wrote:
>
> What are examples of where this would be useful in a database context?
gamma() and lgamma() are the kinds of functions that are generally
useful for a variety of tasks like statistical analysis and
combinatorial computations, and having th
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
On Wed, 21 Aug 2024 at 10:07, jian he wrote:
>
> in Var comments:
>
> * varlevelsup is greater than zero in Vars that represent outer references.
> * Note that it affects the meaning of all of varno, varnullingrels, and
> * varnosyn, all of which refer to the range table of that query level.
>
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
On Thu, 15 Aug 2024 at 05:20, Joel Jacobson wrote:
>
> On Wed, Aug 14, 2024, at 19:25, Joel Jacobson wrote:
> > What do we want to happen if passing a numeric with decimal digits,
> > to decimal_to_bytes()? It must be an error, right?
> >
> > Example: SELECT decimal_to_bytes(1.23);
>
> Hmm, an err
On Wed, 14 Aug 2024 at 07:31, Joel Jacobson wrote:
>
> I think this is acceptable, since it produces more correct results.
>
Thanks for checking. I did a bit more testing myself and didn't see
any problems, so I have committed both these patches.
> In addition, I've traced the rscale_adjustment
On Tue, 13 Aug 2024 at 08:49, Joel Jacobson wrote:
>
> I reran the tests and v5 produces much fewer diffs than v4.
> Not sure if the remaining ones are problematic or not.
>
> joel@Joels-MBP postgresql % ./test-mul_var-verify-v5.sh
> HEAD is now at a67a49648d Rename C23 keyword
> SET
> DROP TABLE
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
On Thu, 8 Aug 2024 at 07:23, Peter Eisentraut wrote:
>
> Thank you for your extensive testing. Here is a new patch set that has
> fixed all the issues you have reported (MERGE, sublinks, statistics,
> ANALYZE).
I had a quick look at this and found one issue, which is that it
doesn't properly dea
n
From 6c1820257997facfe8e74fac8b574c8f683bbebc Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Thu, 18 Jul 2024 17:38:59 +0100
Subject: [PATCH v4 1/2] Extend mul_var_short() to 5 and 6-digit inputs.
Commit ca481d3c9a introduced mul_var_short(), which is used by
mul_var() whenever the shorter inp
On Mon, 29 Jul 2024 at 21:39, Joel Jacobson wrote:
>
> I like these simplifications, how `var2ndigits` is used instead of
> `res_ndigits`:
> - for (int i = res_ndigits - 3; i >= 1; i--)
> + for (int i = var2ndigits - 1; i >= 1; i--)
>
> But I wonder why
On Mon, 29 Jul 2024 at 18:57, Joel Jacobson wrote:
>
> Thanks to v3-0002, they are all still significantly faster when both patches
> have been applied,
> but I wonder if it is expected or not, that v3-0001 temporarily made them a
> bit slower?
>
There's no obvious reason why 0001 would make th
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
On Sat, 20 Jul 2024 at 12:39, Alexander Korotkov wrote:
>
> > The new function replace_relid() looks to be the same as adjust_relid_set().
>
> They are similar, not the same. replace_relid() has handling for
> negative newId, while adjust_relid_set() hasn't. One thing I'd like
> to borrow from a
On Wed, 17 Jul 2024 at 01:45, Alexander Korotkov wrote:
>
> Jian He gave a try to ChangeVarNodes() [1]. That gives some
> improvement, but the vast majority of complexity is still here. I
> think the reason for complexity of SJE is that it's the first time we
> remove relation, which is actually
On Wed, 17 Jul 2024 at 07:29, Andy Fan wrote:
>
> It is just not clear to me how verbose the document should to be, and
> where the document should be, tablefunc.sgml, the comment above the
> function or the places just the code? In many cases you provides above
> or below are just implementation
On Mon, 6 May 2024 at 15:46, Laurenz Albe wrote:
>
> Currently, it is pretty easy to subvert the restrictions imposed
> by row-level security and security_barrier views. All you have to
> to is use EXPLAIN (ANALYZE) and see how many rows were filtered
> out by the RLS policy or the view condition
On Tue, 2 Jul 2024 at 11:18, Jim Jones wrote:
>
> When either minval or maxval exceeds int4 the function cannot be
> executed/found
>
> SELECT * FROM normal_rand_array(5, 10, 8, 42::bigint);
>
> ERROR: function normal_rand_array(integer, integer, integer, bigint)
> does not exist
> LINE 1: SELECT
On Sun, 7 Jul 2024 at 20:46, Joel Jacobson wrote:
>
> This patch adds a mul_var_large() that is dispatched to from mul_var()
> for var1ndigits >= 8, regardless of rscale.
>
> -- var1ndigits == var2ndigits == 16384
> SELECT COUNT(*) FROM n_max WHERE product = var1 * var2;
> Time: 3191.145 ms (00:03
On Sun, 7 Jul 2024 at 13:43, Joel Jacobson wrote:
>
> > SELECT hash_array(array_agg(width_bucket(op, b1, b2, c))) FROM t;
> > -- Result not changed by patch
>
> Same hash_array on all my three machines:
>
> > SELECT sum(width_bucket(op, b1, b2, c)) FROM t;
> > Time: 3658.962 ms (00:03.659) -- HEA
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
On Sat, 6 Jul 2024 at 12:17, Joel Jacobson wrote:
>
> > I think this is good to go, so unless there are any further comments,
> > I plan to commit it soon.
>
> LGTM.
>
OK, I have committed this.
At the last minute, I changed the name of the new function to
mul_var_short() because "short" is prob
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
The numeric round() and trunc() functions clamp the scale argument to
the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
That's a long way short of the actual allowed range of type numeric,
so they produce incorrect results when rounding/truncating more than
2000 digits before or af
In the numeric width_bucket() code, we currently do the following:
mul_var(&operand_var, count_var, &operand_var,
operand_var.dscale + count_var->dscale);
div_var(&operand_var, &bound2_var, result_var,
select_div_scale(&operand_var, &bound2_var), true);
if (cmp
On Fri, 5 Jul 2024 at 18:37, Joel Jacobson wrote:
>
> On Fri, Jul 5, 2024, at 18:42, Joel Jacobson wrote:
> > Very nice, v7-optimize-numeric-mul_var-small-var1-arbitrary-var2.patch
> > is now the winner on all my CPUs:
>
> I thought it would be interesting to also measure the isolated effect
> on
On Fri, 5 Jul 2024 at 12:56, Joel Jacobson wrote:
>
> Interesting you got so bad bench results for v6-mul_var_int64.patch
> for var1ndigits=4, that patch is actually the winner on AMD Ryzen 9 7950X3D.
Interesting.
> On Intel Core i9-14900K the winner is
> v6-optimize-numeric-mul_var-small-var1-
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
On Wed, 3 Jul 2024 at 14:49, Joel Jacobson wrote:
>
> Hmm, I don't see how the case 2 code can be correct?
> If, like you say, res_ndigits can't be less than 3, that means it can be 3,
> right?
> And if res_ndigits=3 then `var2digits[res_ndigits - 4]` would try to access
> `var2digits[-1]`.
>
A
On Wed, 3 Jul 2024 at 08:36, Joel Jacobson wrote:
>
> Hello hackers,
>
> I have discovered a peculiar behavior in mul_var() when it is called with
> rscale=0, but the input variables have many decimal digits, resulting in a
> product with a .5 decimal part. Given that no decimals are requested by
1 - 100 of 651 matches
Mail list logo
