On 7 February 2018 at 13:29, Robert Haas wrote:
> On Wed, Feb 7, 2018 at 3:51 AM, Dean Rasheed wrote:
>> Thanks for testing. I agree, this new algorithm seems to stand up
>> pretty well in the testing I've done too. One thing about it that can
>> be tuned is the cutoff
On 7 February 2018 at 15:25, Robert Haas wrote:
> Do you plan to press forward with this, then, or what's
> the next step?
>
Yes, I think the results are pretty good so far, especially for the
more non-uniform distributions. AFAICS it solves the 2 original
complaints, and I've not yet seen a case
Out of curiosity, what was the original use-case for this?
I'm not objecting to adding it, I'm just curious. In fact, I think
that if we do add this, then we should probably add lcm() at the same
time, since handling its overflow cases is sufficiently non-trivial to
justify not requiring users to
On Thu, 2 Jan 2020 at 15:13, Tom Lane wrote:
>
> Stephen Frost writes:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> I'm not objecting to adding it, I'm just curious. In fact, I think
> >> that if we do add this, then we should probably add lcm
On Sat, 4 Jan 2020 at 09:37, Dean Rasheed wrote:
>
> Well Vik has now provided a numeric implementation and it doesn't
> appear to be too much code.
>
BTW, I did a bit of research into the efficiency of Euclid's
algorithm. It's actually quite interesting:
It turns
On Tue, 3 Dec 2019 at 11:06, Pengzhou Tang wrote:
>
> Hi Hackers,
>
> I hit an error when updating a view with conditional INSTEAD OF rules, the
> reproduce steps are list below:
>
> CREATE TABLE t1(a int, b int);
> CREATE TABLE t2(a int, b int);
> CREATE VIEW v1 AS SELECT * FROM t1 where b > 100
On Sat, 4 Jan 2020 at 17:13, Tom Lane wrote:
>
> Dean Rasheed writes:
> > That included a change to rewriteTargetListIU() to prevent it from
> > adding dummy targetlist entries for unassigned-to attributes for
> > auto-updatable views, in case they are no longer simp
On Sat, 4 Jan 2020 at 17:55, Vik Fearing wrote:
> On 04/01/2020 10:37, Dean Rasheed wrote:
> >
> > BTW, there is actually no need to restrict the inputs to integral
> > values because GCD is something that has a perfectly natural extension
> > to floating point
On Mon, 6 Jan 2020 at 11:01, Tomas Vondra wrote:
>
> On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
>
> >2 We feel that gtt needs to maintain statistics, but there is no
> >agreement on what it will be done.
> >
>
> I certainly agree GTT needs to maintain statistics, otherwise it'll lead
On Sat, 28 Dec 2019 at 16:45, David Fetter wrote:
>
> On Sat, Dec 28, 2019 at 12:12:30AM -0300, Alvaro Herrera wrote:
> > On 2019-Dec-28, David Fetter wrote:
> >
> > > While noodling around with an upcoming patch to remove user-modifiable
> > > RULEs, I noticed that WHEN conditions were disallowed
On Sat, 4 Jan 2020 at 18:12, Dean Rasheed wrote:
>
> On Sat, 4 Jan 2020 at 17:13, Tom Lane wrote:
> >
> > Dean Rasheed writes:
> > > That included a change to rewriteTargetListIU() to prevent it from
> > > adding dummy targetlist entries for unassigned-to
Do we actually need the smallint versions of these functions?
I would have thought that automatic casting would take care of any
cases that need smallints, and I can't believe that there's any
performance benefit to be had that's worth maintaining the extra code.
Regards,
Dean
On Tue, 7 Jan 2020 at 11:00, Dean Rasheed wrote:
>
> Here's a patch along those lines. Yes, it's a little more code
> duplication, but I think it's worth it for the more detailed error.
> There was no previous regression test coverage of this case so I added
>
On Fri, 17 Jan 2020 at 06:14, Pengzhou Tang wrote:
>
> I am wondering whether a simple auto-updatable view can have a conditional
> update instead rule.
Well, the decision reached in [1] was that we wouldn't allow that. We
could decide to allow it now as a new feature enhancement, but it
wouldn'
On Tue, 7 Jan 2020 at 12:31, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Do we actually need the smallint versions of these functions?
>
> Doubt it. It'd be fairly hard even to call those, since e.g. "42"
> is an int not a smallint.
>
I see this has bee
Looking at the docs, I think it's worth going a little further than
just saying what the acronyms stand for -- especially since the
behaviour for zero inputs is an implementation choice (albeit the most
common one). I propose the following:
+
+greatest common divisor — the largest p
On Mon, 20 Jan 2020 at 18:52, Vik Fearing wrote:
>
> On 20/01/2020 11:28, Dean Rasheed wrote:
> >
> > +
> > +least common multiple — the smallest strictly positive number
> > +that is an integer multiple of both inputs; returns
> > 0
On Mon, 20 Jan 2020 at 19:04, Alvaro Herrera wrote:
>
> On 2020-Jan-20, Dean Rasheed wrote:
>
> > +
> > +greatest common divisor — the largest positive number that
> > +divides both inputs with no remainder; returns
> > 0 if
On Mon, 20 Jan 2020 at 08:04, Vik Fearing wrote:
>
> On 20/01/2020 08:44, Dean Rasheed wrote:
> >>
> > I see this has been marked RFC. I'll take it,
>
Committed with some adjustments, mostly cosmetic but a couple more substantive:
The code to guard against a floatin
I just noticed the following:
CREATE TABLE foo (a int, b int);
INSERT INTO foo SELECT x/10, x/100 FROM generate_series(1, 100) x;
CREATE STATISTICS foo_s ON a,b FROM foo;
ANALYSE foo;
SELECT pg_mcv_list_items(stxmcv) from pg_statistic_ext WHERE stxname = 'foo_s';
which fails with
ERROR: cache
On Mon, 29 Apr 2019 at 04:56, Daurnimator wrote:
>
> On Wed, 27 Mar 2019 at 23:46, Dean Rasheed wrote:
> > On second thoughts, it actually needs to be in
> > get_row_security_policies(), after making copies of the quals from the
> > policies, otherwise it would be scrib
While working on 1aebfbea83c, I noticed that the new multivariate MCV
stats feature suffers from the same problem, and also the original
problems that were fixed in e2d4ef8de8 and earlier --- namely that a
user can see values in the MCV lists that they shouldn't see (values
from tables that they do
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
>
> Yeah. I suggest we add a simple pg_stats_ext view, similar to pg_stats.
> It would:
>
> (1) translate the schema / relation / attribute names
>
> I don't see why translating column indexes to names would be fiddly.
> It's a matter of simple
On Fri, 17 May 2019 at 21:29, Andres Freund wrote:
>
> On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > 5). Some columns from pg_statistic_ext have to be made visible for
> > psql \d to work. Basically, it needs to be able to query for the
> > existence of extended st
On Sat, 18 May 2019 at 10:11, Dean Rasheed wrote:
>
> On Fri, 17 May 2019 at 21:29, Andres Freund wrote:
> >
> > On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > > 5). Some columns from pg_statistic_ext have to be made visible for
> > > psql \d to wor
On Sat, 18 May 2019 at 16:13, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On the other hand, pg_dump relies on pg_statistic_ext to work out
> > which extended statistics objects to dump. If we were to change that
> > to use pg_stats_ext, then a user dumping a
On Sun, 19 May 2019 at 00:48, Stephen Frost wrote:
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Tomas Vondra writes:
> >
> > > I think we have four options - rework it before beta1, rework it after
> > > beta1, rework it in PG13 and leave it as it is now.
> >
> > Yup, that's about what the opti
On Sun, 19 May 2019 at 15:28, Tom Lane wrote:
>
> > I wonder ... another way we could potentially do this is
>
> > create table pg_statistic_ext_data(
> > stxoid oid, -- OID of owning pg_statistic_ext entry
> > stxkind char, -- what kind of data
> > stxdata bytea -- the data, in some
On Sun, 19 May 2019 at 23:45, Tomas Vondra wrote:
>
> Oh, right. It still has the disadvantage that it obfuscates the actual
> data stored in the pg_stats_ext_data (or whatever would it be called),
> so e.g. functions would have to do additional checks to make sure it
> actually is the right stati
On Mon, 20 May 2019 at 14:32, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Sun, 19 May 2019 at 23:45, Tomas Vondra
> > wrote:
> >> Oh, right. It still has the disadvantage that it obfuscates the actual
> >> data stored in the pg_stats_ext_data (or whate
On Wed, 3 Oct 2018 at 15:58, Madeleine Thompson wrote:
> This diff looks good to me. Also, it applies cleanly against
> abd9ca377d669a6e0560e854d7e987438d0e612e and passes `make
> check-world`.
>
> I agree that this is not suitable for a patch release.
>
Pushed to master. Thanks for the review.
On Sat, 24 Nov 2018 at 02:09, Tomas Vondra wrote:
> On 11/23/18 12:14 PM, Surafel Temesgen wrote:
> > On Sun, Nov 11, 2018 at 11:59 PM Tomas Vondra
> > mailto:tomas.von...@2ndquadrant.com>> wrote:
> > So, what about using FILTER here? We already use it for aggregates when
> > filtering row
On 1 March 2018 at 21:01, Andres Freund wrote:
> This sounds like the patch's status of "waiting on author" isn't right,
> and it should more be ready for committer?
>
Yes, I'll take a look at it this weekend.
Regards,
Dean
On 7 February 2018 at 15:58, Dean Rasheed wrote:
> On 7 February 2018 at 15:25, Robert Haas wrote:
>> Do you plan to press forward with this, then, or what's
>> the next step?
>
> I plan to do more testing
TL;DR: I tested this new algorithm using 9 different relative
On 6 March 2018 at 08:51, John Naylor wrote:
> On 3/5/18, Dean Rasheed wrote:
>> Attached is an updated patch.
> Nice. The results look good.
Thanks for the review.
> I agree it should be in a separate function. As for that large
> comment, I spent some time pouring over it
On 10 March 2018 at 20:21, Tom Lane wrote:
> I wrote:
>> Whilst fooling about with predtest.c, I noticed a rather embarrassing
>> error. Consider the following, rather silly, CHECK constraint:
>> ...
>> So, what to do? We have a few choices, none ideal:
>
> I'd been assuming that we need to back
On 6 March 2018 at 16:48, Dean Rasheed wrote:
> On 6 March 2018 at 08:51, John Naylor wrote:
>> On 3/5/18, Dean Rasheed wrote:
>>> Attached is an updated patch.
>> Nice. The results look good.
>
> Thanks for the review.
>
So I was about ready to commit thi
> On 03/11/2018 10:23 AM, Dean Rasheed wrote:
>> I'm moving this back to a status of "Needs review" partly because the
>> code has changed significantly, but also because I want to do more
>> testing, particularly with larger datasets.
>>
John, Tomas,
Th
On 13 March 2018 at 08:39, John Naylor wrote:
>> Also, this is common enough that in fact that distribution
>> can be reasonably approximated by a normal distribution.
>
> For the archives, because it's typically seen 10 times in the sample,
> per the rule of thumb mention upthread?
>
Actually, I
On 17 March 2018 at 17:16, Dean Rasheed wrote:
> Using the calculator above, you can see that the distribution is
> fairly normal-like, but with a noticeable positive skew. The 2-stddev
> interval is 0.6 to 9.4, and according to the calculator the
> probability of the value being
On 16 March 2018 at 15:26, Tomas Vondra wrote:
> Actually, one question - when deciding whether to keep the item in the
> MCV list, analyze_mcv_list only compares it's frequency with an average
> of the rest. But as we're removing items from the MCV list, the average
> frequency of the non-MCV ite
On 17 March 2018 at 18:40, Tomas Vondra wrote:
> Currently, analyze_mcv_list only checks if the frequency of the current
> item is significantly higher than the non-MCV selectivity. My question
> is if it shouldn't also consider if removing the item from MCV would not
> increase the non-MCV select
On 18 March 2018 at 12:24, John Naylor wrote:
> Over the weekend I tried out a test to measure:
> -The size of the MCV list
> -The ratio between actual and estimated cardinality of the least
> common value in the MCV list.
> -The ratio between actual and estimated cardinality of the most common
>
On 18 March 2018 at 22:52, Dean Rasheed wrote:
> I'll post something tomorrow, once I've finished wordsmithing the comments.
>
As promised, here is a new patch, with comment updates, per John and
Tomas' suggestions, plus the continuity correction, which seemed just
about
On 19 March 2018 at 16:59, John Naylor wrote:
> On 3/19/18, Dean Rasheed wrote:
>> As promised, here is a new patch, with comment updates, per John and
>> Tomas' suggestions, plus the continuity correction, which seemed just
>> about worthwhile.
>
> Great. I&
On Mon, 22 Jan 2024 at 02:10, Peter Smith wrote:
>
> Hi, this patch was marked in CF as "Needs Review" [1], but there has
> been no activity on this thread for 6+ months.
>
> Is anything else planned? Can you post something to elicit more
> interest in the latest patch? Otherwise, if nothing happe
n Fri, 26 Jan 2024 at 14:59, vignesh C wrote:
>
> CFBot shows that the patch does not apply anymore as in [1]:
>
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index f8f83d4..6ef0c2b
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc
On Fri, 26 Jan 2024 at 15:57, Alvaro Herrera wrote:
>
> Well, firstly this is clearly a feature we want to have, even though
> it's non-standard, because people use it and other implementations have
> it. (Eh, so maybe somebody should be talking to the SQL standard
> committee about it). As for
On Thu, 28 Dec 2023 at 07:34, jian he wrote:
>
> Your patch works.
> performance is the best amount for other options in [0].
> I don't have deep knowledge about which one is more random.
>
Thanks for testing.
> Currently we have to explicitly mention the lower and upper bound.
> but can we do t
gly, the cfbot didn't pick up on the fact that it needed
rebasing. Anyway, the copyright years in the new file's header comment
needed updating, so here is a rebase doing that.
Regards,
Dean
From 15d0ba981ff03eca7143726fe7512adf00ee3a84 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date:
On Tue, 30 Jan 2024 at 12:47, Aleksander Alekseev
wrote:
>
> Maybe I'm missing something but I'm not sure if I understand what this
> test tests particularly:
>
> ```
> -- There should be no triple duplicates in 1000 full-range 32-bit random()
> -- values. (Each of the C(1000, 3) choices of tripl
On Sun, 4 Feb 2024 at 18:19, zwj wrote:
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>
>This issue is related to Megre into and other concurrent statements being
> written.
>I obtained different results in Oracle and PG usin
On Tue, 21 Feb 2023 at 09:34, Alvaro Herrera wrote:
>
> > I think the best fix is to have ExecMergeMatched() pass canSetTag =
> > false to ExecUpdateAct(), so that ExecMergeMatched() takes
> > responsibility for updating estate->es_processed in all cases.
>
> Sounds sensible.
>
I decided it was a
On Mon, 20 Feb 2023 at 16:18, Dean Rasheed wrote:
>
> 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
On Mon, 20 Feb 2023 at 19:49, Dean Rasheed wrote:
>
> 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 to
On Tue, 7 Feb 2023 at 10:56, Dean Rasheed wrote:
>
> Attached is a more complete patch
>
Rebased version attached.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..ff2a827
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml
Attached is a patch fixing a few doc omissions for MERGE.
I don't think that it's necessary to update every place that could
possibly apply to MERGE, but there are a few places where we give a
list of commands that may be used in a particular context, and I think
those should mention MERGE, if it
On Fri, 24 Feb 2023 at 08:56, Alvaro Herrera wrote:
>
> Agreed. Your patch looks good to me.
>
> I was confused for a bit about arch-dev.sgml talking about ModifyTable
> when perform.sgml talks about Insert/Update et al; I thought at first
> that one or the other was in error, so I checked. It t
On Fri, 24 Feb 2023 at 09:28, Dean Rasheed wrote:
>
> On Fri, 24 Feb 2023 at 08:56, Alvaro Herrera wrote:
> >
> > I assume you're proposing to back-patch this.
>
> Yes. Will do.
>
Done.
Regards,
Dean
On Fri, 24 Feb 2023 at 05:46, Dean Rasheed wrote:
>
> Rebased version attached.
>
Another rebase.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..ff2a827
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml/dml.sgml
@@ -283,1
Now that we have random_normal(), it seems like it would be useful to
add the error functions erf() and erfc(), which I think are
potentially useful to the people who will find random_normal() useful,
and possibly others.
An immediate use for erf() is that it allows us to do a
Kolmogorov-Smirnov t
On Thu, 2 Mar 2023 at 19:58, David Rowley wrote:
>
> I think I'd prefer to see the size_bytes_unit_alias struct have an
> index into size_pretty_units[] array. i.e:
>
> struct size_bytes_unit_alias
> {
> const char *alias; /* aliased unit name */
> const int unit_index; /* corresponding si
On Fri, 3 Mar 2023 at 11:23, David Rowley wrote:
>
> On Fri, 3 Mar 2023 at 09:32, Dean Rasheed wrote:
> > Hmm, I think it would be easier to just have a separate table for
> > pg_size_bytes(), rather than reusing pg_size_pretty()'s table.
>
> Maybe that's worth
> On 20.02.23 23:16, Joel Jacobson wrote:
> > In the new attached patch, Andres fixed buffer idea has been implemented
> > throughout the entire numeric.c code base.
>
I have been going over this patch, and IMO it's far too invasive for
the fairly modest performance gains (and performance regressi
On Tue, 28 Feb 2023 at 07:44, Peter Eisentraut
wrote:
>
> Attached is a patch to add nondecimal integer literals and underscores
> in numeric literals to the SQL JSON path language. This matches the
> recent additions to the core SQL syntax. It follows ECMAScript in
> combination with the curren
On Wed, 8 Mar 2023 at 20:11, Nathan Bossart wrote:
>
> On Mon, Feb 27, 2023 at 12:54:35PM +, Dean Rasheed wrote:
> > + /*
> > + * For erf, we don't need an errno check because it never overflows.
> > + */
>
> > + /*
> > + * Fo
On Wed, 8 Mar 2023 at 23:24, Thomas Munro wrote:
>
> No comment on the maths, but I'm pretty sure we won't need a fallback
> implementation. That stuff goes back to the math libraries of 80s
> Unixes, even though it didn't make it into C until '99. I just
> checked the man pages for all our targ
On Thu, 9 Mar 2023 at 00:13, Nathan Bossart wrote:
>
> On Wed, Mar 08, 2023 at 11:29:12PM +, Dean Rasheed wrote:
> > On Wed, 8 Mar 2023 at 20:11, Nathan Bossart
> > wrote:
> >> The man pages for these seem to indicate that underflow can occur. Do we
> >>
On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov wrote:
>
> I wonder why does ExecMergeMatched() determine the lock mode using
> ExecUpdateLockMode(). Why don't we use lock mode set by
> table_tuple_update() like ExecUpdate() does? I skim through the
> MERGE-related threads, but didn't find an a
> On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov wrote:
> >
> > I wonder why does ExecMergeMatched() determine the lock mode using
> > ExecUpdateLockMode(). Why don't we use lock mode set by
> > table_tuple_update() like ExecUpdate() does? I skim through the
> > MERGE-related threads, but didn
On Sun, 26 Feb 2023 at 09:50, Dean Rasheed wrote:
>
> Another rebase.
>
And another rebase.
Regards,
Dean
diff --git a/doc/src/sgml/dml.sgml b/doc/src/sgml/dml.sgml
new file mode 100644
index cbbc5e2..ff2a827
--- a/doc/src/sgml/dml.sgml
+++ b/doc/src/sgml/dml.sgml
@@ -283,10 +283,15
I see the PlaceHolderVar issue turned out to be a pre-existing bug after all.
Rebased version attached.
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
+++ b/doc/src/sgml/mvcc.sgml
@@ -396,8 +396,8
On Tue, 21 Mar 2023 at 10:28, Alvaro Herrera wrote:
>
> > + /* Combine it with the action's WHEN condition */
> > + if (action->qual == NULL)
> > + action->qual = (Node *) ntest;
> > + else
> > +
On Fri, 15 Mar 2024 at 11:06, Dean Rasheed wrote:
>
> Updated patch attached.
>
I have gone over this patch again in detail, and I believe that the
code is in good shape. All review comments have been addressed, and
the only thing remaining is the syntax question.
To recap, this add
On Sat, 16 Mar 2024 at 17:25, Tom Lane wrote:
>
> After looking at your draft some more, it occurred to me that we're
> not that far from getting rid of showing "$n" entirely in this
> context. Instead of (subplan_name).$n, we could write something like
> (subplan_name).colN or (subplan_name).col
On Fri, 15 Mar 2024 at 17:14, Jeff Davis wrote:
>
> On Fri, 2024-03-15 at 11:20 +, Dean Rasheed wrote:
>
> > So barring any further objections, I'd like to go ahead and get this
> > patch committed.
>
> I like this feature from a user perspective. So +1 f
On Sun, 17 Mar 2024 at 19:39, Tom Lane wrote:
>
> Here's a cleaned-up version that seems to successfully resolve
> PARAM_EXEC references in all cases. I haven't changed the
> "(plan_name).colN" notation, but that's an easy fix once we have
> consensus on the spelling.
I took a more detailed look
On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>
> > Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> > a bit odd to my eye.
>
> After thinking a bit more, I understood what was bothering me about
> that notation: it looks too much like a call of a user-defined
> function named "
On Sat, 16 Mar 2024 at 17:36, Ayush Vatsa wrote:
>
> Attached is the complete patch with all the required code changes.
> Looking forward to your review and feedback.
>
This looks good to me. I tested it and everything worked as expected.
I ran it through pgindent to fix some whitespace issues a
On Tue, 19 Mar 2024 at 16:42, Tom Lane wrote:
>
> Here's a hopefully-final version that makes that adjustment and
> tweaks a couple of comments.
>
This looks very good to me.
One final case that could possibly be improved is this one from aggregates.out:
explain (verbose, costs off)
select arra
On Tue, 19 Mar 2024 at 21:40, Tom Lane wrote:
>
> I'm inclined to leave that alone. The actual source sub-SELECT
> could only have had one column, so no real confusion is possible.
> Yeah, there's a resjunk grouping column visible in the plan as well,
> but those exist in many other queries, and
On Tue, 19 Mar 2024 at 19:17, Ayush Vatsa wrote:
>
> > I'm marking this ready-for-commit (which I'll probably do myself in a
> > day or two, unless anyone else claims it first).
>
> Thank you very much, this marks my first contribution to the open-source
> community, and I'm enthusiastic about ma
On Wed, 20 Mar 2024 at 09:43, Peter Eisentraut wrote:
>
> On 19.03.24 10:57, jian he wrote:
> > this new syntax need to be added into the alter_domain.sgml's synopsis and
> > also
> > need an explanation varlistentry?
>
> The ALTER DOMAIN reference page refers to CREATE DOMAIN about the
> details
On Fri, 22 Mar 2024 at 08:28, jian he wrote:
>
> On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut wrote:
> >
> > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax. Attached is a patch to try to sort this out.
>
> also you should also change src/
On Tue, 27 Feb 2024 at 17:33, Dean Rasheed wrote:
>
> On Sat, 24 Feb 2024 at 17:10, Tomas Vondra
> >
> > I did a quick review and a little bit of testing on the patch today. I
> > think it's a good/useful idea, and I think the code is ready to go (the
> >
On Thu, 21 Mar 2024 at 09:35, Dean Rasheed wrote:
>
> Trivial rebase forced by 6185c9737c.
>
I think it would be good to get this committed.
It has had a decent amount of review, at least up to v9, but a number
of things have changed since then:
1). Concurrent update behaviour --
On Tue, 26 Mar 2024 at 07:30, Alvaro Herrera wrote:
>
> On 2024-Mar-25, Dean Rasheed wrote:
>
> > Also (not this patch's fault), psql doesn't seem to offer a way to
> > display domain constraint names -- something you need to know to drop
> > or alter them.
On Tue, 26 Mar 2024 at 06:57, Dean Rasheed wrote:
>
> Based on the reviews so far, I think this is ready for commit, so
> unless anyone objects, I will do so in a day or so.
>
Committed. Thanks for the reviews.
Regards,
Dean
On Wed, 27 Mar 2024 at 07:47, Jeff Davis wrote:
>
> This isn't a complete review, but I spent a while looking at this, and
> it looks like it's in good shape.
Thanks for looking.
> I like the syntax, and I think the solution for renaming the alias
> ("RETURNING WITH (new as n, old as o)") is a g
> > On 19 Feb 2024, at 12:48, Tom Lane wrote:
> >
> > Or we could just flush it. It's never detected a bug, and I think
> > you'd find that it adds zero code coverage (or if not, we could
> > fix that in a far more surgical and less expensive manner).
>
Off the top of my head, I can't say to wha
On Mon, 19 Feb 2024 at 15:35, Tom Lane wrote:
>
> I thought I'd try to acquire some actual facts here, so I compared
> the code coverage shown by "make check" as of HEAD, versus "make
> check" after adding numeric_big to parallel_schedule. I saw the
> following lines of numeric.c as being covered
On Mon, 19 Feb 2024 at 17:48, zwj wrote:
>
> Hello,
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>This question is about 'merge into'.
>
>When two merge into statements are executed concurrently, I obtain the
> following pro
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> Also, if the concurrent update were an update of a key
> column that was included in the join condition, the re-scan would
> follow the update to a new matching source row, which is inconsistent
> with what would happen if it w
On Tue, 20 Feb 2024 at 15:16, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Looking at the script itself, the addition, subtraction,
> > multiplication and division tests at the top are probably pointless,
> > since I would expect those operations to be tested adequatel
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> On the face of it, the simplest fix is to tweak is_simple_union_all()
> to prevent UNION ALL subquery pullup for MERGE, forcing a
> subquery-scan plan. A quick test shows that that fixes the reported
> issue.
>
> How
On Thu, 22 Feb 2024 at 03:46, zwj wrote:
>
> If I want to get the same results as Oracle, do I need to adjust the lock
> behavior of the update and merge statements?
> If I want to achieve the same results as Oracle, can I achieve exclusive
> locking by adjusting update and merge? Do you ha
On Fri, 23 Feb 2024 at 14:35, Peter Eisentraut wrote:
>
> Various code comments say that the RangeTblEntry field inh may only be
> set for entries of kind RTE_RELATION.
>
> The function pull_up_simple_union_all() in prepjointree.c sets ->inh to
> true for RTE_SUBQUERY entries:
>
> /*
>
On Fri, 23 Feb 2024 at 00:12, Tom Lane wrote:
>
> So after studying this for awhile, I see that the planner is emitting
> a PlanRowMark that presumes that the UNION ALL subquery will be
> scanned as though it's a base relation; but since we've converted it
> to an appendrel, the executor just igno
h "uniform"
as the default distribution, if omitted.
For different result datatypes, it ought to be mostly possible to
determine the result type from the arguments. There might be some
exceptions, like maybe "random_bytes(length)" to generate a byte
array, but I think that would
On Wed, 28 Feb 2024 at 09:16, jian he wrote:
>
> + oldcontext = MemoryContextSwitchTo(estate->es_query_cxt);
> +
> + node->as_epq_tupdesc = lookup_rowtype_tupdesc_copy(tupType, tupTypmod);
> +
> + ExecAssignExprContext(estate, &node->ps);
> +
> + node->ps.ps_ProjInfo =
> + ExecBuildProjectionInfo(
101 - 200 of 649 matches
Mail list logo
