On Tue, 21 Mar 2023 at 12:26, Alvaro Herrera wrote:
>
> On 2023-Mar-21, Dean Rasheed wrote:
>
> > Looking at it with fresh eyes though, I realise that I could have just
> > written
> >
> > action->qual = make_and_qual((Node *) ntest, action->qual)
On Thu, 6 Jul 2023 at 06:13, Gurjeet Singh wrote:
>
> Most of the review was done with the v6 of the patch, minus the doc
> build step. The additional changes in v7 of the patch were eyeballed,
> and tested with `make check`.
>
Thanks for the review!
> > One minor annoyance is that, due to the w
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
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 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
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 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, 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 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 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, 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 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 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 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 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 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 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 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
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 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
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 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
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 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 Fri, 12 Jun 2020 at 20:53, Tom Lane wrote:
>
> I wrote:
> > Before v12, stddev_pop() had the following behavior with just a
> > single input value:
> > ...
> > As of v12, though, all three cases produce 0. I am not sure what
> > to think about that with respect to an infinity input, but I'm
>
On Fri, 12 Jun 2020 at 02:16, Tom Lane wrote:
>
> * I had to invent some semantics for non-standardized functions,
> particularly numeric_mod, numeric_gcd, numeric_lcm. This area
> could use review to be sure that I chose desirable behaviors.
>
I think the semantics you've chosen for numeric_mod
On Tue, 16 Jun 2020 at 06:00, Ashutosh Bapat
wrote:
>
> Divison by zero is really undefined, 12345678 * 12345678 (just some numbers)
> is out of range of say int4, but factorial of a negative number has some
> meaning and is defined but PostgreSQL does not support it.
>
Actually, I think undefi
On Tue, 16 Jun 2020 at 09:55, Bruce Momjian wrote:
>
> On Tue, Jun 16, 2020 at 08:31:21AM +0100, Dean Rasheed wrote:
> >
> > Most common implementations do regard factorial as undefined for
> > anything other than positive integers, as well as following the
> > co
On Tue, 16 Jun 2020 at 10:09, Juan José SantamarÃa Flecha
wrote:
>
> It is defined as NaN (or undefined), which is not in the realm of integer
> numbers. You might get a clear idea of the logic from [1], where they also
> make a case for the error being ERRCODE_DIVISION_BY_ZERO.
>
> [1] http://m
On Tue, 16 Jun 2020 at 12:18, Peter Eisentraut
wrote:
>
> On 2020-06-16 11:49, Dean Rasheed wrote:
> > With [1], we could return 'Infinity', which would be more correct from
> > a mathematical point of view, and might be preferable to erroring-out
> > in some
On Tue, 16 Jun 2020 at 18:24, Tom Lane wrote:
>
> The attached v3 patch fixes these things and also takes care of an
> oversight in v2: I'd made numeric() apply typmod restrictions to Inf,
> but not numeric_in() or numeric_recv(). I believe the patch itself
> is in pretty good shape now, though t
On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> I wrote:
> > When the current row's value is +infinity, actual computation of
> > base - offset would yield NaN, making it a bit unclear whether
> > we should consider -infinity to be in-range. It seems to me that
> > we should, as that gives more na
On Thu, 16 Jul 2020 at 20:29, Tom Lane wrote:
>
> Dean Rasheed questioned this longstanding behavior:
>
> regression=# SELECT 'nan'::float8 / '0'::float8;
> ERROR: division by zero
>
> After a bit of research I think he's right: per IEEE 754 this sh
On Fri, 17 Jul 2020 at 01:59, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> >> Actually, after staring at those results awhile longer, I decided
> >> they were wrong. The results shown here seem actually sane --
On Mon, 4 May 2020 at 22:22, Tom Lane wrote:
>
> * is also quite sticky about inserting other sorts
> of font-changing environments inside it. As an example, it'll let
> you include but not , which seems pretty weird
> to me. This is problematic in some places where it's desirable to
> have te
On Wed, 6 Feb 2019 at 23:44, Tomas Vondra wrote:
>
> On 2/6/19 10:59 PM, David Rowley wrote:
> > On Thu, 7 Feb 2019 at 03:16, Alvaro Herrera
> > wrote:
> >> I wonder what should we be doing with this series -- concretely, should
> >> the effort concentrate on one of the two patches, and leave th
So I started looking into the bug noted in [1], but before getting to
multi-row inserts, I concluded that the current single-row behaviour
isn't spec-compliant.
In particular, Syntax Rule 11b of section 14.11 says that an INSERT
statement on a GENERATED ALWAYS identity column must specify an
overr
On Mon, 25 Feb 2019 at 12:47, Peter Eisentraut
wrote:
> > - and the column in new rows will automatically have values from the
> > - sequence assigned to it.
> > + and new rows in the column will automatically have values from the
> > + sequence assigned to them.
>
> The "it" r
On Tue, 12 Feb 2019 at 10:33, Dean Rasheed wrote:
> Here's an updated patch ...
So I pushed that. However, ...
Playing around with it some more, I realised that whilst this appeared
to fix the reported problem, it exposes another issue which is down to
the interaction
On Mon, 24 Dec 2018 at 23:57, Corey Huinker wrote:
>
> So I took a first pass at this, and I got stuck.
>
> [snip]
>
> Any idea where I went wrong?
Take a look at this code in AfterTriggerSaveEvent():
/*
* If the trigger is a deferred unique constraint check trigger, only
On Tue, 25 Dec 2018 at 08:04, Dean Rasheed wrote:
> Take a look at this code in AfterTriggerSaveEvent():
>
Note that the intention behind that code is that in the (fairly
common) case where an insert or update operation is known to not lead
to any potential PK/UNIQUE index violation
On Mon, 7 Jan 2019 at 00:45, Tomas Vondra wrote:
>
> FWIW the main unsolved issue (at least on the MCV part) is how it
> decides which items to keep in the list.
>
> As explained in [1], in the multivariate case we can't simply look at
> the group frequency and compare it to the average frequency
On Wed, 9 Jan 2019 at 23:24, Andrew Dunstan
wrote:
> Here's another attempt. For the rewrite case it kept the logic of the
> previous patch to clear all the missing attributes, but if we're not
> rewriting we reconstruct the missing value according to the new type
> settings.
>
Looks good to me.
Has the policy on cross-posting to multiple lists been hardened recently?
The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
message on 8 Jan with an initial proposed patch and my response later
that day both CC'ed -hackers and seem to have been rejected, and so
are missing from
On Wed, 9 Jan 2019 at 15:40, Tomas Vondra wrote:
> On 1/8/19 3:18 PM, Dean Rasheed wrote:
> > So actually, the estimate for a group of values will be either the MCV
> > item's frequency (if the MCV item is kept), or (roughly) the MCV
> > item's base_frequency (if
On Wed, 26 Dec 2018 at 22:09, Tomas Vondra wrote:
>
> Attached is an updated version of the patch - rebased and fixing the
> warnings reported by Thomas Munro.
>
Here are a few random review comments based on what I've read so far:
On the CREATE STATISTICS doc page, the syntax in the new exampl
On Fri, 11 Jan 2019, 21:18 Tomas Vondra
> On 1/10/19 4:20 PM, Dean Rasheed wrote:
> > ...
> >
> > So perhaps what we should do for multivariate stats is simply use the
> > relative standard error approach (i.e., reuse the patch in [2] with a
> > 20% RSE cutoff).
On Sun, 13 Jan 2019 at 00:04, Tomas Vondra wrote:
> On 1/12/19 8:49 AM, Dean Rasheed wrote:
> > A possible refinement would be to say that if there are more than
> > stats_target items more common than this mincount threshold, rather than
> > excluding the least common o
(Removing Adrien from the CC list, because messages to that address
keep bouncing)
On Sun, 13 Jan 2019 at 00:31, Tomas Vondra wrote:
>
> On 1/10/19 6:09 PM, Dean Rasheed wrote:
> >
> > In the previous discussion around UpdateStatisticsForTypeChange(), the
> > consensu
On Thu, 17 Jan 2019 at 03:42, David Rowley wrote:
> 35. The evaluation order of this macro is wrong.
>
> #define ITEM_SIZE(ndims) \
> (ndims * (sizeof(uint16) + sizeof(bool)) + 2 * sizeof(double))
>
> You'd probably want ITEM_SIZE(10) to return 170, but:
>
> select (10 * (2 + 1) + 2 * 8);
> ?colu
On Thu, 17 Jan 2019 at 03:42, David Rowley wrote:
> 39. I don't see analyze_mcv_list() being used anywhere around this comment:
>
> * If we can fit all the items onto the MCV list, do that. Otherwise use
> * analyze_mcv_list to decide how many items to keep in the MCV list, just
> * like for the s
On Wed, 29 Jan 2020 at 21:39, Tom Lane wrote:
>
> >>> pg_stat_statements
>
> Mmm, I'm not convinced --- the ability to see what statements are being
> executed in other sessions (even other databases) is something that
> paranoid installations might not be so happy about. Our previous
> discussio
Attached is a WIP patch to improve the performance of numeric sqrt()
and ln(), which also makes a couple of related improvements to
div_var_fast(), all of which have knock-on benefits for other numeric
functions. The actual impact varies greatly depending on the inputs,
but the overall effect is to
On Fri, 28 Feb 2020 at 08:15, Dean Rasheed wrote:
>
> It's possible that there are further gains to be had in the sqrt()
> algorithm on platforms that support 128-bit integers, but I haven't
> had a chance to investigate that yet.
>
Rebased patch attached, now using 128
On Tue, 3 Mar 2020 at 00:17, Tels wrote:
>
> Thank you for these patches, these sound like really nice improvements.
Thanks for looking!
> One thing can to my mind while reading the patch:
>
> +* If r < 0 Then
> +* Let r = r + 2*s - 1
> +
On Wed, 4 Mar 2020 at 14:41, David Steele wrote:
>
> Are these improvements targeted at PG13 or PG14? This seems a pretty
> big change for the last CF of PG13.
>
Well of course that's not entirely up to me, but I was hoping to
commit it for PG13.
It's very well covered by a large number of regr
On Fri, 6 Mar 2020 at 12:58, Tomas Vondra wrote:
>
> Here is a rebased version of this patch series. I've polished the first
> two parts a bit - estimation of OR clauses and (Var op Var) clauses.
>
Hi,
I've been looking over the first patch (OR list support). It mostly
looks reasonable to me, ex
On Mon, 9 Mar 2020 at 00:02, Tomas Vondra wrote:
>
> Speaking of which, would you take a look at [1]? I think supporting SAOP
> is fine, but I wonder if you agree with my conclusion we can't really
> support inclusion @> as explained in [2].
>
Hmm, I'm not sure. However, thinking about your examp
On Thu, 6 Jun 2019 at 21:33, Tomas Vondra wrote:
>
> Hi,
>
> Attached are three patches tweaking the stats - two were already posted
> in this thread, the third one is just updating docs.
>
> 1) 0001 - split pg_statistic_ext into definition + data
>
> This is pretty much the patch Dean posted some
On Tue, 18 Jun 2019 at 21:59, Tomas Vondra wrote:
>
> The current implementation of multi-column MCV lists (added in this
> cycle) uses a fairly simple algorithm to pick combinations to include in
> the MCV list. We just compute a minimum number of occurences, and then
> include all entries sample
On Tue, 18 Jun 2019 at 22:34, Tomas Vondra wrote:
>
> One slightly inconvenient thing I realized while playing with the
> address data set is that it's somewhat difficult to set the desired size
> of the multi-column MCV list.
>
> At the moment, we simply use the maximum statistic target for attri
On Thu, 20 Jun 2019 at 23:12, Tomas Vondra wrote:
>
> On Thu, Jun 20, 2019 at 08:08:44AM +0100, Dean Rasheed wrote:
> >On Tue, 18 Jun 2019 at 22:34, Tomas Vondra
> >wrote:
> >>
> >> So I'm thinking we should allow tweaking the statistics for ext
On Thu, 20 Jun 2019 at 23:35, Tomas Vondra wrote:
>
> On Thu, Jun 20, 2019 at 06:55:41AM +0100, Dean Rasheed wrote:
>
> >I'm not sure it's easy to justify ordering by Abs(freq-base_freq)/freq
> >though, because that would seem likely to put too much weight on
On Mon, 13 May 2019 at 23:36, Tomas Vondra wrote:
>
> On Fri, May 10, 2019 at 10:19:44AM +0100, Dean Rasheed wrote:
> >While working on 1aebfbea83c, I noticed that the new multivariate MCV
> >stats feature suffers from the same problem, and also the original
> >pro
On Sat, 22 Jun 2019 at 15:10, Tomas Vondra wrote:
> One annoying thing I noticed is that the base_frequency tends to end up
> being 0, most likely due to getting too small. It's a bit strange, though,
> because with statistic target set to 10k the smallest frequency for a
> single column is 1/3e6,
On Mon, 24 Jun 2019 at 00:42, Tomas Vondra wrote:
>
> On Sun, Jun 23, 2019 at 10:23:19PM +0200, Tomas Vondra wrote:
> >On Sun, Jun 23, 2019 at 08:48:26PM +0100, Dean Rasheed wrote:
> >>On Sat, 22 Jun 2019 at 15:10, Tomas Vondra
> >>wrote:
> >>&g
On Sat, 29 Jun 2019 at 14:01, Tomas Vondra wrote:
>
> >However, it looks like the problem is with mcv_list_items()'s use
> >of %f to convert to text, which is pretty ugly.
>
> >>>There's one issue with the signature, though - currently the function
> >>>returns null flags as bool arra
On 24 June 2018 at 20:45, Tomas Vondra wrote:
> Attached is a rebased version of this patch series, mostly just fixing
> the breakage caused by reworked format of initial catalog data.
>
> Aside from that, the MCV building now adopts the logic introduced by
> commit b5db1d93d2 for single-column MC
On 13 July 2018 at 18:27, Tomas Vondra wrote:
> I'm not so sure. The issue is that a lot of the MCV deductions depends
> on whether we can answer questions like "Is there a single match?" or
> "If we got a match in MCV, do we need to look at the non-MCV part?" This
> is not very different from the
On 15 July 2018 at 14:29, Tomas Vondra wrote:
> It's quite unclear to me how this algorithm could reliably end up with
> hist_sel=0 (in cases where we already don't end up with that). I mean,
> if a bucket matches the conditions, then the only way to eliminate is by
> deducing that MCV already con
On 16 July 2018 at 13:23, Tomas Vondra wrote:
>>> The top-level clauses allow us to make such deductions, with deeper
>>> clauses it's much more difficult (perhaps impossible). Because for
>>> example with (a=1 AND b=1) there can be just a single match, so if we
>>> find it in MCV we're done. With
On 16 July 2018 at 21:55, Tomas Vondra wrote:
>
>
> On 07/16/2018 02:54 PM, Dean Rasheed wrote:
>> On 16 July 2018 at 13:23, Tomas Vondra wrote:
>>>>> The top-level clauses allow us to make such deductions, with deeper
>>>>> clauses it's muc
Last week I upgraded 15 servers from various pre-10 versions to 10.4.
At first everything looked OK, but then (around 4 days later) one of
them failed with this in the logs:
2018-07-14 01:53:35.840 BST LOG: could not generate random cancel key
2018-07-14 01:53:37.233 BST LOG: could not generat
On 17 July 2018 at 14:04, Michael Paquier wrote:
> On Tue, Jul 17, 2018 at 01:33:11PM +0100, Dean Rasheed wrote:
>> Looking for precedents elsewhere, I found [2] which does exactly that,
>> although I'm slightly dubious about the need for the for-loop there. I
>> also
On 18 July 2018 at 03:17, Michael Paquier wrote:
>> [1] https://wiki.openssl.org/index.php/Random_Numbers
>
> This quote from the wiki is scary so that's not quite clean either for
> Windows:
> "Be careful when deferring to RAND_poll on some Unix systems because it
> does not seed the generator. S
On 18 July 2018 at 14:01, Michael Paquier wrote:
> Thanks for the updated version. This looks safer to me. It is possible
> to simplify the code by removing the external RAND_status() call and
> check for RAND_status() first in the loop as per the attached.
OK, thanks.
Barring any further comm
On 26 July 2018 at 07:12, Ashutosh Bapat
wrote:
> In the patch clauselist_selectivity() gets called repeatedly for every
> new qual added to the clause list. Instead, if we try to combine the
> cost/row estimation with order_qual_clauses() or
> clauselist_selectivity(), we might be able to what th
On 15 May 2018 at 22:55, Tom Lane wrote:
> David Rowley writes:
>> On 16 May 2018 at 02:01, Tom Lane wrote:
>>> I'm not particularly fussed about getting credit for that. However,
>>> looking again at how that patch series turned out --- ie, that
>>> we ensured POSIX behavior for NaNs only in H
On 16 May 2018 at 14:44, Tom Lane wrote:
> Dean Rasheed writes:
>> In the case 1 ^ NaN = 1, what should the result scale be?
>
> The result is exact, so I don't see a reason to be worried about its
> scale. Messing with the scale would also require expending even
> mo
On 28 October 2017 at 13:46, Pavel Stehule wrote:
> I though about Alexander proposal, and I am thinking so it can be probably
> best if we respect psql design. I implemented two command suffixes
> (supported only when it has sense) "s" sorted by size and "d" as descent
>
> so list of tables can b
On 5 August 2017 at 10:03, Fabien COELHO wrote:
>
> Hello Rod,
>
> Patch applies cleanly, make html ok, new table looks good to me.
>
> I've turned it "Ready for Committer".
>
I didn't really finish committing this in the last commitfest, before
getting distracted by a security issue, so returnin
On 26 November 2017 at 22:56, Tom Lane wrote:
> Etsuro Fujita writes:
>> [ fix-rewrite-tlist-v4.patch ]
>
> I started reviewing this patch. I did not much like the fact that it
> effectively moved rewriteTargetListUD to a different file and renamed it.
> That seems like unnecessary code churn, p
On 27 November 2017 at 16:35, Tom Lane wrote:
> I wrote:
>> Dean Rasheed writes:
>>> A separate point -- it might be marginally more efficient to have the
>>> work of rewriteTargetListUD() done after expand_targetlist() to avoid
>>> the possible renumbering
AFAICS this patch does nothing to consider parallel safety -- that is,
as things stand, a variable is allowed in a query that may be
parallelised, but its value is not copied to workers, leading to
incorrect results. For example:
create table foo(a int);
insert into foo select * from generate_seri
On 3 September 2018 at 00:17, Tomas Vondra wrote:
> Hi,
>
> Attached is an updated version of the patch series, adopting a couple of
> improvements - both for MCV lists and histograms.
>
>
> MCV
> ---
>
> For the MCV list part, I've adopted the approach proposed by Dean, using
> base selectivity a
On 27 September 2018 at 06:12, Madeleine Thompson wrote:
> This is my first PostgreSQL review. Hopefully I'm getting it right. I
> independently ran into the bug in question and found that the author had
> already written a patch. I'm happy the author wrote this.
>
Thanks for the review. And ye
On Thu, 27 Sep 2018 at 14:22, Dean Rasheed wrote:
> I'll post an updated patch in a while.
>
I finally got round to looking at this again. Here is an update, based
on the review comments.
The next question is whether or not to back-patch this. Although this
was reported as a bug, my
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 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 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 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
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 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 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
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 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 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 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
501 - 600 of 690 matches
Mail list logo
