On Sat, 28 Mar 2020 at 13:18, Dean Rasheed wrote:
>
> OK, I've pushed that with your recommendation for that function name.
>
Does this now complete everything that you wanted to do for functional
dependency stats for PG13? Re-reading the thread, I couldn't see
anything else
On Tue, 31 Mar 2020 at 04:39, David Rowley wrote:
>
> On Sat, 28 Mar 2020 at 22:22, David Rowley wrote:
> > I'm unsure yet if this has caused an instability on lousyjack's run in
> > [1].
>
> pogona has just joined in on the fun [1], so, we're not out the woods
> on this yet. I'll start having a
On Tue, 31 Mar 2020 at 22:16, Tom Lane wrote:
>
> > Dean Rasheed writes:
> >> ...
> >> It looks to me as though the problem is that statext_store() needs to
> >> take its lock on pg_statistic_ext_data *before* searching for the
> >> stats tuple to upd
I was thinking some more about the recent fix to multi-row VALUES
handling in the rewriter (b8f2687fdc), and I realised that there is
another bug in the way DEFAULT values are handled:
In RewriteQuery(), the code assumes that in a multi-row INSERT query,
the VALUES RTE will be the only thing in th
While playing around with rules and MERGE, I noticed that there is a
bug in the way that it detects whether the target table has rules ---
it uses rd_rel->relhasrules, which can be incorrect, since it might be
set for a table that doesn't currently have rules, but did in the
recent past.
So it act
On Tue, 22 Nov 2022 at 13:37, Peter Eisentraut
wrote:
>
> On 15.11.22 11:31, Peter Eisentraut wrote:
> > On 14.11.22 08:25, John Naylor wrote:
> >> Regarding the patch, it looks good overall. My only suggestion would
> >> be to add a regression test for just below and just above overflow, at
> >>
On Wed, 23 Nov 2022 at 15:30, Tom Lane wrote:
>
> > So I think what the code needs to do is examine the targetlist, and
> > identify the VALUES RTE that the current query is using as a source,
> > and rewrite just that RTE (so any original VALUES RTE is rewritten at
> > the top level, and any VALU
On Wed, 23 Nov 2022 at 15:32, Tom Lane wrote:
>
> Not quite sure the added test case is worth the cycles.
>
No, probably not, for such a trivial change.
Pushed to HEAD and 15, without the test. Thanks for looking!
Regards,
Dean
On Wed, 23 Nov 2022 at 18:56, Tom Lane wrote:
>
> I wonder if somehow we could just make one pass over
> all the VALUES RTEs, and process each one as needed? The problem
> is to identify the relevant target relation, I guess.
>
I have been thinking about that some more, but I think it would be
p
On Wed, 23 Nov 2022 at 08:56, David Rowley wrote:
>
> On Wed, 23 Nov 2022 at 21:54, David Rowley wrote:
> > I wonder if you'd be better off with something like:
> >
> > while (*ptr && isxdigit((unsigned char) *ptr))
> > {
> > if (unlikely(tmp & UINT64CONST(0xF0
On Wed, 30 Nov 2022 at 05:50, David Rowley wrote:
>
> I spent a bit more time trying to figure out why the compiler does
> imul instead of bit shifting and it just seems to be down to a
> combination of signed-ness plus the overflow check. See [1]. Neither
> of the two compilers I tested could use
On Thu, 1 Dec 2022 at 02:58, David Rowley wrote:
>
> On Thu, 1 Dec 2022 at 15:41, David G. Johnston
> wrote:
> > I don't get the point of adding a function here (or at least one called
> > round) - the type itself is inexact so, as you say, it is actually more of
> > a type conversion with an a
On Thu, 1 Dec 2022 at 05:38, David Rowley wrote:
>
> On Thu, 1 Dec 2022 at 18:27, John Naylor wrote:
> > I don't see why the non-decimal literal patch needs to be "immediately"
> > faster? If doing this first leads to less code churn, that's another
> > consideration, but you haven't made that
On Sun, 4 Dec 2022 at 03:19, David Rowley wrote:
>
> Pushed with some small adjustments.
>
Ah, I see that you changed the overflow test, and I realise that I
forgot to answer your question about why I wrote that as 1 - INT_MIN /
10 over on the other thread.
The reason is that we need to detect w
While testing MERGE, I noticed that it supports inheritance
hierarchies and the ONLY keyword, but that isn't documented. Attached
is a patch to merge.sgml, borrowing text from update.sgml and
delete.sgml.
I note that there are also a couple of places early in the manual
(advanced.sgml and ddl.sgml
On Fri, 9 Dec 2022 at 10:02, Alvaro Herrera wrote:
>
> On 2022-Dec-08, Nathan Bossart wrote:
>
> > On Thu, Dec 08, 2022 at 03:26:52PM +0000, Dean Rasheed wrote:
> > > While testing MERGE, I noticed that it supports inheritance
> > > hierarchies and the ONLY k
On Mon, 26 Apr 2021 at 15:09, Tom Lane wrote:
>
> Thanks for looking at that. On reflection I think this must be so,
> because those rewriter mechanisms were designed long before we had
> trigger-updatable views, and rewriteTargetListIU has never added
> tlist items like this for any other sort o
On Mon, 26 Apr 2021 at 15:55, Tom Lane wrote:
>
> I checked into the commit history (how'd we ever survive without "git
> blame"?) and found that my argument above is actually wrong in detail.
> Before cab5dc5da of 2013-10-18, rewriteTargetListIU expanded non-updated
> columns for all views not on
On Wed, 19 May 2021 at 00:35, Thomas Munro wrote:
>
> FWIW this is reproducible on my local Debian/gcc box with -m32,
Confirmed, thanks for looking. I can reproduce it on my machine with
-m32. It's somewhat annoying that the buildfarm didn't pick it up
sooner :-(
On Wed, 19 May 2021 at 08:28, Mi
On Wed, 19 May 2021 at 11:32, Fabien COELHO wrote:
>
> >> Or, (3) remove this test? I am not quite sure what there is to gain
> >> with this extra test considering all the other tests with permute()
> >> already present in this script.
> >
> > Yes, I think removing the test is the best option. It
On Wed, 19 May 2021 at 12:07, Fabien COELHO wrote:
>
> Attached patch disactivates the test with comments to outline that there
> is an issue to fix… so it is *not* removed.
>
I opted to just remove the test rather than comment it out, since the
issue highlighted isn't specific to permute(). Also
On Tue, 10 Jan 2023 at 14:43, Dean Rasheed wrote:
>
> Rebased version attached.
>
Rebased version, following 8eba3e3f02 and 5d29d525ff.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index b87ad5c..1482ede
--- a/doc/src/sgml/mvcc.sgml
On Mon, 9 Jan 2023 at 17:44, Dean Rasheed wrote:
>
> On Mon, 9 Jan 2023 at 16:23, Vik Fearing wrote:
> >
> > Bikeshedding here. Instead of Yet Another WITH Clause, could we perhaps
> > make a MERGING() function analogous to the GROUPING() function that goes
> > wit
On Sun, 22 Jan 2023 at 13:42, Joel Jacobson wrote:
>
> Hi,
>
> On platforms where we support 128bit integers, we could accelerate division
> when the number of digits in the divisor is larger than 8 and less than or
> equal to 16 digits, i.e. when the divisor that fits in a 64-bit integer but
> w
On Sun, 22 Jan 2023 at 15:41, Joel Jacobson wrote:
>
> On Sun, Jan 22, 2023, at 11:06, Dean Rasheed wrote:
> > Seems like a reasonable idea, with some pretty decent gains.
> >
> > Note, however, that for a divisor having fewer than 5 or 6 digits,
> > it's no
On Mon, 23 Jan 2023 at 05:06, John Naylor wrote:
>
> According to Agner's instruction tables [1], integer division on Skylake (for
> example) has a latency of 26 cycles for 32-bit operands, and 42-95 cycles for
> 64-bit.
>
> [1] https://www.agner.org/optimize/instruction_tables.pdf
>
Thanks, th
On Sun, 22 Jan 2023 at 22:49, Joel Jacobson wrote:
>
> Many thanks for feedback. Nice catch! New patch attached.
>
Cool, that resolves the performance issues I was seeing for smaller
divisors (which also had a noticeable impact on the numeric_big
regression test).
After some more testing, the ga
On Mon, 23 Jan 2023 at 15:55, Peter Eisentraut
wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
&
On Sun, 22 Jan 2023 at 19:08, Alvaro Herrera wrote:
>
> > diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
> > new file mode 100644
> > index e34f583..aa3cca0
> > --- a/src/backend/commands/copy.c
> > +++ b/src/backend/commands/copy.c
> > @@ -274,12 +274,6 @@ DoCopy(ParseStat
On Wed, 4 Jan 2023 at 09:28, Dean Rasheed wrote:
>
> In addition, I think that strip_underscores() could then go away if
> numeric_in() were made to handle underscores.
>
> Essentially then, that would move all responsibility for parsing
> underscores and non-decimal intege
On Mon, 23 Jan 2023 at 20:00, Joel Jacobson wrote:
>
> Nice! This also simplifies when dealing with non-negative integers
> represented as byte arrays,
> common in e.g. cryptography code.
>
Ah, interesting. I hadn't thought of that use-case.
> create function numeric_from_bytes(bytea) returns n
On Tue, 24 Jan 2023 at 00:47, Ranier Vilela wrote:
>
> On 13.01.23 11:01, Dean Rasheed wrote:
> > So I'm feeling quite good about the end result -- I set out hoping not
> > to make performance noticeably worse, but ended up making it
> > significantly better.
&g
I only recently realised that to_hex() converts its input to unsigned
before converting it to hex (something that's not mentioned in the
docs):
to_hex(-1) ->
I think that's something that some users might find surprising,
especially if they were expecting to be able to use it to output
On Tue, 24 Jan 2023 at 13:43, Aleksander Alekseev
wrote:
>
> Adding extra arguments for something the user can implement
> (him/her)self doesn't seem to be a great idea. With this approach we
> may end up with hundreds of arguments one day.
>
I don't see how a couple of extra arguments will expan
On Wed, 18 Jan 2023 at 15:25, Justin Pryzby wrote:
>
> TBH, I think the best approach is what I did in:
> 0001-report-top-parent-progress-for-CREATE-INDEX.txt
>
> That's a minimal patch, ideal for backpatching.
>
> ..which defines/clarifies that the progress reporting is only for
> *direct* childr
On Wed, 25 Jan 2023 at 09:02, Aleksander Alekseev
wrote:
>
> > I don't see how a couple of extra arguments will expand to hundreds.
>
> Maybe I was exaggerating, but the point is that adding extra flags for
> every possible scenario is a disadvantageous approach in general.
> There is no need to i
On Wed, 25 Jan 2023 at 10:57, Aleksander Alekseev
wrote:
>
> > Of course there is. This is easy to code in C using unsigned ints,
> > without resorting to abs() (yes, I'm aware that abs() is undefined for
> > INT_MIN).
>
> So in your opinion what is the expected result of to_hex(INT_MIN,
> with_si
On Wed, 25 Jan 2023 at 21:43, Peter Eisentraut
wrote:
>
> On 24.01.23 14:10, Dean Rasheed wrote:
> > I also think it might be useful for it to gain a couple of boolean options:
> >
> > 1). An option to output a signed value (defaulting to false, to
> > preserve the c
I spent a little time investigating bug #17759 [1] in more detail.
Initially, I thought that it had been fixed by 3f7836ff65, but it
turns out that's not the case.
[1]
https://www.postgresql.org/message-id/17759-e76d9bece1b5421c%40postgresql.org
The immediate cause of the bug was that, before 3f
On Sat, 28 Jan 2023 at 22:14, Joel Jacobson wrote:
>
> I found what appears to be a small harmless error in numeric.c,
> that seems worthwhile to fix only because it's currently causes confusion.
>
Shrug. Looking at git blame, it's been like that for about 20 years,
and I wasn't aware of it causi
On Tue, 31 Jan 2023 at 08:00, Joel Jacobson wrote:
>
> I think this is what we want:
>
> if (arg.weight < 0)
> sweight = (arg.weight + 1) * DEC_DIGITS / 2 - 1;
> else
> sweight = arg.weight * DEC_DIGITS / 2 + 1;
>
That's still not right. If you want
On Tue, 31 Jan 2023 at 15:28, Peter Eisentraut
wrote:
>
> Did you have any thoughts about what to do with the float types? I
> guess we could handle those in a separate patch?
>
I was assuming that we'd do nothing for float types, because anything
we did would necessarily impact their performanc
On Tue, 31 Jan 2023 at 15:05, Joel Jacobson wrote:
>
> I also think the performance impact no matter how small isn't worth it,
> but a comment based on your comments would be very valuable IMO.
>
> Below is an attempt at summarising your text, and to avoid the performance
> impact,
> maybe an #if
On Wed, 1 Feb 2023 at 12:12, Alvaro Herrera wrote:
>
> I had tried to tie these relations using WITH ORDINALITY, but the only
> way I could think of (array_agg to then unnest() WITH ORDINALITY) was
> even uglier than what I already had. So yeah, I think it might be
> useful if we had a way to inj
On Tue, 31 Jan 2023 at 21:59, Joel Jacobson wrote:
>
> Nice, you managed to simplify it even further.
> I think the comment and the code now are crystal clear together.
>
> I've tested it successfully, test report attached.
>
Cool. Thanks for testing.
Committed.
Regards,
Dean
On Thu, 2 Feb 2023 at 06:40, Tom Lane wrote:
>
> Noah Misch writes:
> > Regarding the concern about a pre-receive hook blocking an emergency push,
> > the
> > hook could approve every push where a string like "pgindent: no" appears in
> > a
> > commit message within the push. You'd still want
On Thu, 2 Feb 2023 at 22:40, Peter Eisentraut
wrote:
>
> On 31.01.23 17:09, Dean Rasheed wrote:
> > On Tue, 31 Jan 2023 at 15:28, Peter Eisentraut
> > wrote:
> >>
> >> Did you have any thoughts about what to do with the float types? I
> >> gu
On Sat, 21 Jan 2023 at 14:18, Ted Yu wrote:
>
> On Sat, Jan 21, 2023 at 3:05 AM Dean Rasheed wrote:
>>
>> Rebased version, following 8eba3e3f02 and 5d29d525ff.
>>
Another rebased version attached.
> In transform_MERGE_to_join :
>
> +
On Mon, 23 Jan 2023 at 16:54, Dean Rasheed wrote:
>
> On Sun, 22 Jan 2023 at 19:08, Alvaro Herrera wrote:
> >
> > Regarding mas_action_idx, I would have thought that it belongs in
> > MergeAction rather than MergeActionState. After all, you determine it
> > o
On Mon, 20 Feb 2023 at 08:03, Joel Jacobson wrote:
>
> On Mon, Feb 20, 2023, at 08:38, Michael Paquier wrote:
> > Perhaps you should register this patch to the commit of March? Here
> > it is:
> > https://commitfest.postgresql.org/42/
>
> Thanks, done.
>
I have been testing this a bit, and I get
Playing around with MERGE some more, I noticed that the command tag
row count is wrong if it does a cross-partition update:
CREATE TABLE target (a int, b int) PARTITION BY LIST (b);
CREATE TABLE target_p1 PARTITION OF target FOR VALUES IN (1);
CREATE TABLE target_p2 PARTITION OF target FOR VALUES
As part of the MERGE RETURNING patch I noticed a suspicious Assert()
in ExecInitPartitionInfo() that looked like it needed updating for
MERGE.
After more testing, I can confirm that this is indeed a pre-existing
bug, that can be triggered using MERGE into a partitioned table that
has RLS enabled (
Another one noticed from the MERGE RETURNING patch -- the switch
statement in SPI_result_code_string() is missing cases for
SPI_OK_TD_REGISTER and SPI_OK_MERGE.
The SPI_OK_TD_REGISTER case goes back all the way, so I suppose it
should be back-patched to all supported branches, though evidently
thi
On Mon, 20 Feb 2023 at 19:39, Tom Lane wrote:
>
> Ugh. Grepping around, it looks like pltcl_process_SPI_result
> is missing a case for SPI_OK_MERGE as well.
>
Yes, I was about to post a patch for that too. That's the last case
that I found, looking around.
Regards,
Dean
Another one noticed in the MERGE RETURNING patch -- this allows PL/Tcl
to execute MERGE (i.e., don't fail when SPI returns SPI_OK_MERGE). I'm
not sure if anyone uses PL/Tcl anymore, but it's a trivial fix,
probably not worth a regression test case.
Regards,
Dean
diff --git a/src/pl/tcl/pltcl.c b/s
[Moving this to -hackers]
> On 13/10/2022 18:20 CEST Adrian Klaver wrote:
> > select power(10, -18::numeric);
> > power
> >
> > 0.
> >
On Thu, 13 Oct 2022 at 18:17, Tom Lane wrote:
>
> An inexact result isn't surprising, but it shouldn't be *that* inexact.
>
On Tue, 18 Oct 2022 at 20:18, Robert Haas wrote:
>
> On Tue, Oct 18, 2022 at 6:18 AM Dean Rasheed wrote:
> > Overall, I'm quite happy with these results. The question is, should
> > this be back-patched?
> >
> > In the past, I think I've only back-patche
On Thu, 3 Jun 2021 at 08:26, Michael Paquier wrote:
>
> Hi all,
>
> serinus has been complaining about the new gcd functions in 13~:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-06-03%2003%3A44%3A14
>
> The overflow detection is going wrong the way up and down, like he
On Sun, 13 Jun 2021 at 21:28, Tomas Vondra
wrote:
>
> Here is a slightly updated version of the patch
>
> The main issue I ran into
> is the special case clauselist_selectivity, which does
>
> if (list_length(clauses) == 1)
> return clause_selectivity_ext(...);
>
> which applies to c
I found a couple of places where numeric multiplication suffers from
overflow errors for inputs that aren't necessarily very large in
magnitude.
The first is with the numeric * operator, which attempts to always
produce the exact result, even though the numeric type has a maximum
of 16383 digits a
Thanks for looking!
On Mon, 28 Jun 2021 at 12:27, David Rowley wrote:
>
> Instead of adding a send/recv function, unless I'm mistaken, it should
> be possible to go the whole hog and optimizing this further by instead
> of having numericvar_send(), add:
>
> static void numericvar_serialize(String
Numeric x^y is supported for x < 0 if y is an integer, but this
currently fails if y is outside the range of an int32:
SELECT (-1.0) ^ 2147483647;
?column?
-
-1.
(1 row)
SELECT (-1.0) ^ 2147483648;
ERROR: cannot take logarithm of a negative number
beca
When specifying NUMERIC(precision, scale) the scale is constrained to
the range [0, precision], which is per SQL spec. However, at least one
other major database vendor intentionally does not impose this
restriction, since allowing scales outside this range can be useful.
A negative scale implies
On Tue, 29 Jun 2021 at 21:34, Robert Haas wrote:
>
> I thought about this too, but
> http://postgr.es/m/774767.1591985...@sss.pgh.pa.us made me think that
> it would be an on-disk format break. Maybe it's not, though?
>
No, because the numeric dscale remains non-negative, so there's no
change to
On Thu, 1 Jul 2021 at 02:00, David Rowley wrote:
>
> I kinda disagree with the send/recv naming since all you're using them
> for is to serialise/deserialise the NumericVar. Functions named
> *send() and recv() I more expect to return a bytea so they can be used
> for a type's send/recv function.
On Thu, 1 Jul 2021 at 10:27, Dean Rasheed wrote:
>
> I'll post an update in a while. Thanks for the review.
>
One other thing I'm wondering about is back-patching. I was originally
thinking of these as back-patchable bug fixes, but changing the binary
format of the aggregate s
On Thu, 1 Jul 2021 at 06:43, David Rowley wrote:
>
> Master @ 3788c6678
>
> Execution Time: 8306.319 ms
> Execution Time: 8407.785 ms
> Execution Time: 8491.056 ms
>
> Master + numeric-agg-sumX2-overflow-v2.patch
> Execution Time: 6633.278 ms
> Execution Time: 6657.350 ms
> Execution Time: 6568.18
On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
>
> Numeric x^y is supported for x < 0 if y is an integer, but this
> currently fails if y is outside the range of an int32
>
I've been doing some more testing of this, and I spotted another
problem with numeric_power().
On Thu, 1 Jul 2021 at 19:41, Tom Lane wrote:
>
> Anyway, after taking a very quick look at the patch itself, I've
> got just one main objection: I don't approve of putting this in
> port.h or src/port/.
I haven't looked at the patch in detail, but one thing I object to is
the code to choose a ran
On Thu, 1 Jul 2021 at 22:18, Fabien COELHO wrote:
>
> > However, this patch seems to be replacing that with a simple
> > modulo operation, which is perhaps the worst possible way to do it.
>
> The modulo operation is biased for large ranges close to the limit, sure.
> Also, the bias is somehow of
On Fri, 2 Jul 2021 at 10:24, David Rowley wrote:
>
> I ran this again with a few different worker counts after tuning a few
> memory settings so there was no spilling to disk and so everything was
> in RAM. Mostly so I could get consistent results.
>
> Here's the results. Average over 3 runs on ea
On Fri, 2 Jul 2021 at 12:56, David Rowley wrote:
>
> On Fri, 2 Jul 2021 at 22:55, Dean Rasheed wrote:
> > Here's an update with the
> > last set of changes discussed.
>
> Looks good to me.
Thanks for the review and testing!
> Just the question of if we have any
Attached is a more complete patch, with updated docs and tests.
I chose to allow the scale to be in the range -1000 to 1000, which, to
some extent, is quite arbitrary. The upper limit of 1000 makes sense,
because nearly all numeric computations (other than multiply, add and
subtract) have that as
On Sat, 3 Jul 2021 at 08:06, Fabien COELHO wrote:
>
> Here is a v4, which:
>
> - moves the stuff to common and fully removes random/srandom (Tom)
> - includes a range generation function based on the bitmask method (Dean)
> but iterates with splitmix so that the state always advances once
On Sun, 4 Jul 2021 at 10:35, Fabien COELHO wrote:
>
> I did not understand why it is not correct.
>
Well, to make it easier to visualise, let's imagine our word size is
just 3 bits instead of 64 bits, and that the basic prng() function
generates numbers in the range [0,8). Similarly, imagine a sp
On Sun, 4 Jul 2021 at 17:03, Fabien COELHO wrote:
>
> > As for determinism, the end result is still fully deterministic.
>
> The result is indeed deterministic of you call the function with the same
> range. However, if you change the range value in one place then sometimes
> the state can advance
On Fri, 2 Jul 2021 at 19:48, Ranier Vilela wrote:
>
> If you allow me a small suggestion.
> Move the initializations of the variable tmp_var to after check if the
> function can run.
> Saves some cycles, when not running.
>
OK, thanks. I agree, on grounds of neatness and consistency with
nearby
On Sun, 4 Jul 2021 at 09:43, David Rowley wrote:
>
> On Sat, 3 Jul 2021 at 11:04, Dean Rasheed wrote:
> > Thinking about this more, I think it's best not to risk back-patching.
> > It *might* be safe, but it's difficult to really be sure of that. The
> > bug
On Sun, 13 Jun 2021 at 21:28, Tomas Vondra
wrote:
>
> Here is a slightly updated version of the patch
>
Hi,
I have looked at this in some more detail, and it all looks pretty
good, other than some mostly cosmetic stuff.
The new code in statext_is_compatible_clause_internal() is a little
hard to
On Tue, 6 Jul 2021 at 10:20, David Rowley wrote:
>
> I made another pass over this and ended up removing the doHalfRound
> field in favour of just doing rounding based on the previous
> bitshifts.
>
When I first read this:
+/* half-round until we get down to unitBits */
+
On Tue, 6 Jul 2021 at 13:15, David Rowley wrote:
>
> Can you give an example where calling half_rounded too many times will
> give the wrong value? Keeping in mind we call half_rounded the number
> of times that the passed in value would need to be left-shifted by to
> get the equivalent truncated
On Sun, 18 Apr 2021 at 21:42, Tom Lane wrote:
>
> > If multiple references are actually possible then this'd break it.
>
> I think this patch doesn't make things any worse for such a case though.
> If we re-introduced such a bug, the result would be an immediate null
> pointer crash while trying t
On Sun, 4 Jul 2021 at 09:32, Tatsuo Ishii wrote:
>
> >> So overall gain by the patch is around 15%, whereas the last test
> >> before the commit was 14%. It seems the patch is still beneficial
> >> after the commit.
> >
> > Yes, that's good!
>
> Yeah!
>
I tested this with -s100 and got similar r
On Wed, 7 Jul 2021 at 04:00, Yura Sokolov wrote:
>
> Anyway, excuse me for heating this discussion cause of such
> non-essential issue.
> I'll try to control myself and don't proceed it further.
>
Whilst it has been interesting learning and discussing all these
different techniques, I think it's
On Wed, 7 Jul 2021 at 03:47, David Rowley wrote:
>
> Updated patch attached.
>
Hmm, this looked easy, but...
It occurred to me that there ought to be regression tests for the edge
cases where it steps from one unit to the next. So, in the style of
the existing regression tests, I tried the follo
On Thu, 1 Jul 2021 at 14:17, Dean Rasheed wrote:
>
> On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
> >
> > Numeric x^y is supported for x < 0 if y is an integer, but this
> > currently fails if y is outside the range of an int32
>
> I've been doing so
On Wed, 7 Jul 2021 at 18:57, Zhihong Yu wrote:
>
> + (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> +errmsg("value overflows numeric format")));
>
> Here is an example of existing error message which I think is more readable
> than 'overflows numeric format'
On Thu, 8 Jul 2021 at 05:30, David Rowley wrote:
>
> On Thu, 8 Jul 2021 at 13:31, David Rowley wrote:
> > It feels like if we're going to fix this negative rounding thing then
> > we should maybe do it and backpatch a fix then rebase this work on top
> > of that.
Yes, that was my thinking too.
On Thu, 8 Jul 2021 at 09:26, Fabien COELHO wrote:
>
> > Finally, I think it would be better to treat the upper bound of the
> > range as inclusive.
>
> This bothered me as well, but the usual approach seems to use range as the
> number of values, so I was hesitant to depart from that. I'm still
>
On Thu, 8 Jul 2021 at 14:38, David Rowley wrote:
>
> I gave it a bit of exercise by running pgbench and calling this procedure:
>
> It ran 8526956 times, so with the loop that's 8.5 billion random
> numbers. No variations between the two functions. I got the same
> after removing the 0 - to test
On Thu, 8 Jul 2021 at 14:40, vignesh C wrote:
>
> On Thu, Jul 8, 2021 at 1:52 AM Daniel Gustafsson wrote:
> >
> > I sort of like the visual cue of seeing ereport(ERROR .. since it makes it
> > clear it will break execution then and there, this will require a lookup for
> > anyone who don't know
On Sat, 10 Jul 2021 at 11:44, Dean Rasheed wrote:
>
> I'm inclined to think that it isn't worth the effort trying to
> distinguish between conflicting options, options specified more than
> once and faked-up options that weren't really specified. If we just
> make er
On Sat, 10 Jul 2021 at 18:30, Tom Lane wrote:
>
> [ moving to pghackers for wider visibility ]
>
> Dean Rasheed writes:
> > On Sat, 10 Jul 2021 at 16:01, Tom Lane wrote:
> >> In general, I'm disturbed that we just threw away the previous
> >> promise
On Sat, 10 Jul 2021 at 17:03, vignesh C wrote:
>
> > Also, I don't think this function should be marked inline -- using a
> > normal function ought to help make the compiled code smaller.
>
> inline instructs the compiler to attempt to embed the function content
> into the calling code instead of
On Sat, 10 Jul 2021 at 18:09, vignesh C wrote:
>
> I'm planning to handle conflicting errors separately after this
> current work is done, once the patch is changed to have just the valid
> scenarios(removing the scenarios you have pointed out) existing
> function can work as is without any chang
On Fri, 24 Jun 2022 at 22:44, Tom Lane wrote:
>
> Commit 64919aaab made pull_up_simple_subquery set rte->subquery = NULL
> after doing the deed, so that we don't waste cycles copying a
> now-useless subquery tree around. I discovered today while
> working on another patch that if you invoke query
On Sat, 25 Jun 2022 at 04:39, Tom Lane wrote:
>
> Well, if we want to clean this up a bit rather than just doing the
> minimum safe fix ... I spent some time why we were bothering with the
> FLATCOPY step at all, rather than just mutating the Query* pointer.
> I think the reason is to not fail if
This was discussed previously in [1], and there seemed to be general
consensus in favour of it, but no new patch emerged.
Attached is a patch that takes the approach of not generating an alias
at all, which seems to be neater and simpler, and less code than
trying to generate a unique alias.
It s
On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote:
>
> It doesn't play that well if you have something called subquery though:
>
> [example that changes a user-provided alias]
>
> While the output is a valid query, it's not nice that it's replacing a
> user provided alias with another one (or for
On Mon, 27 Jun 2022 at 19:43, David G. Johnston
wrote:
>
> On Mon, Jun 27, 2022 at 11:25 AM Dean Rasheed
> wrote:
>>
>> On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote:
>> >
>> > It doesn't play that well if you have something called subquery th
301 - 400 of 648 matches
Mail list logo
