On 26 September 2017 at 00:42, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> Attached is a proposed patch...
>
> I've taken a look through this and generally agree with it.
Thanks for looking at this.
> the bits inside ... tags should be
>
On 5 August 2017 at 10:03, Fabien COELHO wrote:
> Patch applies cleanly, make html ok, new table looks good to me.
>
So I started looking at this patch, but before even considering the
new table proposed, I think there are multiple issues that need to be
resolved with the current docs:
Firstly,
On 14 September 2017 at 03:49, Noah Misch wrote:
> On Wed, Sep 13, 2017 at 12:06:40PM -0400, Robert Haas wrote:
>> OK, thanks. I still don't really like allowing this, but I can see
>> that compatibility with other systems has some value here, and if
>> nobody else is rejecting these cases, maybe
On 13 September 2017 at 14:51, Robert Haas wrote:
> Coincidentally, I wrote a patch for this too, but mine goes back to
> rejecting MINVALUE or MAXVALUE followed by anything else.
>
LGTM, if we decide to go this way.
One minor review comment -- you missed an example code snippet using
(MINVALUE,
On 13 September 2017 at 10:05, Amit Langote
wrote:
> Coincidentally, I just wrote the patch for canonicalizing stored values,
> instead of erroring out. Please see attached if that's what you were
> thinking too.
>
Looks reasonable to me, if we decide to go this way.
One minor review comment --
On 13 September 2017 at 14:53, Robert Haas wrote:
> On Wed, Sep 13, 2017 at 4:51 AM, Dean Rasheed
> wrote:
>> A drawback to doing this is that we lose compatibility with syntaxes
>> supported by other databases, which was part of the reason for
>> choosing the terms MINV
Robert Haas writes:
> On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera
> wrote:
>> Did anything happen on this, or did we just forget it completely?
>
> I forgot it. :-(
>
> I really think we should fix this.
Ah, sorry. This was for me to follow up, and I dropped the ball.
Here's a patch resto
On 9 August 2017 at 13:03, Robert Haas wrote:
> On Tue, Aug 8, 2017 at 11:34 PM, Tom Lane wrote:
>> A small suggestion is that it'd be better to write it like "Specified
>> upper bound \"%s\" precedes lower bound \"%s\"." I think "succeeds" has
>> more alternate meanings than "precedes", so the
On 8 August 2017 at 19:22, Robert Haas wrote:
> On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed
> wrote:
>> Also drop the constraint prohibiting finite values after an unbounded
>> column, and just document the fact that any values after MINVALUE or
>> MAXVALUE are ig
On 31 July 2017 at 12:53, Beena Emerson wrote:
> The commit d363d42bb9a4399a0207bd3b371c966e22e06bd3 changed
> RangeDatumContent *content to PartitionRangeDatumKind *kind but a
> comment on function partition_rbound_cmp was left unedited and it
> still mentions content1 instead of kind1.
>
> PFA t
On 17 July 2017 at 17:37, Dean Rasheed wrote:
> On 17 July 2017 at 16:34, Robert Haas wrote:
>> Do you want to own this open item, then?
>>
> OK.
>
> I need to give the patch another read-through, and then I'll aim to
> push it sometime in the next few da
On 17 July 2017 at 16:34, Robert Haas wrote:
> On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed
> wrote:
>> Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can
>> also be done using using MINVALUE/MAXVALUE, by artificially adding
>> another partition
On 14 July 2017 at 06:12, Robert Haas wrote:
> I agree that it's a big problem that (10, UNBOUNDED)
> interpreted as a maximum value means first_column <= 10 and when
> interpreted as a minimum value means first_column >= 10, because those
> things aren't opposites of each other. I guess the prop
On 12 July 2017 at 10:46, Ashutosh Bapat
wrote:
> On Wed, Jul 12, 2017 at 12:54 AM, Dean Rasheed
> wrote:
>> On 11 July 2017 at 13:29, Ashutosh Bapat
>>> The description in this paragraph seems to be attaching intuitive
>>> meaning of word "unbounded&qu
On 12 July 2017 at 23:23, Dean Rasheed wrote:
> I also agree that there probably isn't much need for a list that
> *only* includes partitions, but if someone comes up with a convincing
> use case, then we could add another 2-letter command for that.
>
Actually, I just thought
On 12 July 2017 at 15:58, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2017/07/11 13:34, Alvaro Herrera wrote:
>> > However, the "list tables"
>> > command \dt should definitely IMO not list partitions.
>>
>> Do you mean never? Even if a modifier is specified? In the patch I
>> proposed, \d
On 11 July 2017 at 13:29, Ashutosh Bapat
wrote:
> +
> + Also note that some element types, such as timestamp,
> + have a notion of "infinity", which is just another value that can
> + be stored. This is different from MINVALUE and
> + MAXVALUE, which are not real values th
On 6 July 2017 at 22:43, Joe Conway wrote:
> I agree we should get this right the first time and I also agree with
> Dean's proposal, so I guess I'm a +2
>
On 7 July 2017 at 03:21, Amit Langote wrote:
> +1 to releasing this syntax in PG 10.
>
So, that's 3 votes in favour of replacing UNBOUNDED
On 7 July 2017 at 03:21, Amit Langote wrote:
> The patch looks generally good, although I found and fixed some minor
> issues (typos and such). Please find attached the updated patch.
>
Thanks for the review. Those changes all look good. I also see that I
missed an example in the docs at the bot
On 6 July 2017 at 21:04, Tom Lane wrote:
> Dean Rasheed writes:
>> However, this is also an incompatible syntax change, and any attempt
>> to support both the old and new syntaxes is likely to be messy, so we
>> really need to get consensus on whether this is the righ
On 5 July 2017 at 18:07, Dean Rasheed wrote:
> So if we were to go for maximum flexibility and compatibility with
> Oracle, then perhaps what we would do is more like the original idea
> of UNBOUNDED ABOVE/BELOW, except call them MINVALUE and MAXVALUE,
> which conveniently are alread
On 5 July 2017 at 10:43, Amit Langote wrote:
> 0001 is your patch to tidy up check_new_partition_bound() (must be
> applied before 0002)
>
I pushed this first patch, simplifying check_new_partition_bound() for
range partitions, since it seemed like a good simplification, but note
that I don't th
On 5 July 2017 at 10:43, Amit Langote wrote:
> In retrospect, that sounds like something that was implemented in the
> earlier versions of the patch, whereby there was no ability to specify
> UNBOUNDED on a per-column basis. So the syntax was:
>
> FROM { (x [, ...]) | UNBOUNDED } TO { (y [, ...])
On 5 July 2017 at 10:43, Amit Langote wrote:
>> So the more I think about this, the more I think that a cleaner design
>> would be as follows:
>>
>> 1). Don't allow UNBOUNDED, except in the first column, where it can
>> keep it's current meaning.
>>
>> 2). Allow the partition bounds to have fe
On 3 July 2017 at 10:32, Amit Langote wrote:
> On 2017/07/03 17:36, Dean Rasheed wrote:
>> The bigger question is do we want this for PG10? If so, time is
>> getting tight. My feeling is that we do, because otherwise we'd be
>> changing the syntax in PG11 of a feature
On 3 July 2017 at 06:00, Amit Langote wrote:
> On 2017/07/03 2:15, Dean Rasheed wrote:
>> My first thought was UNBOUNDED ABOVE/BELOW, because that matches the
>> terminology already in use of upper and lower bounds.
>
> I was starting to like the Ashutosh's suggeste
On 30 June 2017 at 10:04, Ashutosh Bapat
wrote:
> On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote
> wrote:
>>
>> Alright, I spent some time implementing a patch to allow specifying
>> -infinity and +infinity in arbitrary ways. Of course, it prevents
>> nonsensical inputs with appropriate error mes
On 30 June 2017 at 09:06, Amit Langote wrote:
> When testing the patch, I realized that the current code in
> check_new_partition_bound() that checks for range partition overlap had a
> latent bug that resulted in false positives for the new cases that the new
> less restrictive syntax allowed. I
On 23 June 2017 at 08:01, Ashutosh Bapat
wrote:
> The way we have designed our syntax, we don't have a way to tell that
> p3 comes after p2 and they have no gap between those. But I don't
> think that's your question. What you are struggling with is a way to
> specify a lower bound (10, +infinity)
On 20 June 2017 at 03:01, Amit Langote wrote:
> Hmm, yes. The following exercise convinced me.
>
> create table r (a int) partition by range (a);
> create table r1 partition of r for values from (1) to (10);
> create rule "_RETURN" as on select to r1 do instead select * from r;
>
> insert into r
On 20 June 2017 at 03:01, Amit Langote wrote:
> On 2017/06/19 20:19, Dean Rasheed wrote:
>> Currently we allow rules to be defined on table partitions, but these
>> rules only fire when the partition is accessed directly, not when it
>> is accessed via the parent:
>
> Y
Currently we allow rules to be defined on table partitions, but these
rules only fire when the partition is accessed directly, not when it
is accessed via the parent:
CREATE TABLE t1(a int, b int) PARTITION BY RANGE(a);
CREATE TABLE t1_p PARTITION OF t1 FOR VALUES FROM (1) TO (10);
INSERT INTO t1
On 13 June 2017 at 05:50, Ashutosh Bapat
wrote:
> On Tue, Jun 13, 2017 at 12:03 AM, Dean Rasheed
> wrote:
>> Barring objections, I'll push my original patch and work up patches
>> for the other couple of issues I found.
>
> No objections, the patch is good to go
On 13 June 2017 at 05:50, Ashutosh Bapat
wrote:
> On Tue, Jun 13, 2017 at 12:03 AM, Dean Rasheed
> wrote:
>> My initial thought, looking at the patch, is that it might be better
>> to have all the macros in one file to make them easier to maintain.
>
> Right now the macr
On 12 June 2017 at 17:51, Joe Conway wrote:
> On 06/12/2017 07:40 AM, Joe Conway wrote:
>> On 06/12/2017 01:49 AM, Amit Langote wrote:
>>> As he mentioned in his reply, Ashutosh's proposal to abstract away the
>>> relkind checks is interesting in this regard.
>>>
>> I have not looked at Ashutosh's
On 11 June 2017 at 20:19, Tom Lane wrote:
>> The standard way of doing this is to calculate the "standard error" of
>> the sample proportion - see, for example [3], [4]:
>> SE = sqrt(p*(1-p)/n)
>> Note, however, that this formula assumes that the sample size n is
>> small compared to the populat
On 11 June 2017 at 16:59, Joe Conway wrote:
> On 06/11/2017 08:55 AM, Joe Conway wrote:
>> Yeah, I noticed the same while working on the RLS related patch. I did
>> not see anything else in rewriteHandler.c but it is probably worth
>> looking wider for other omissions.
>
> So in particular:
>
> #d
On 05/06/17 09:30, Tom Lane wrote:
> First, I think we need a larger hard floor on the number of occurrences
> of a value that're required to make ANALYZE decide it is a "most common
> value"...
>
> Second, the code also has a rule that potential MCVs need to have an
> estimated frequency at least
Hi,
It looks like relation_is_updatable() didn't get the message about
partitioned tables. Thus, for example, information_schema.views and
information_schema.columns report that simple views built on top of
partitioned tables are non-updatable, which is wrong. Attached is a
patch to fix this.
I t
On 23 April 2017 at 03:37, Bruce Momjian wrote:
> In looking at the new multi-column statistics "dependency" option in
> Postgres 10, I am quite confused by the term "dependency". Wouldn't
> "correlation" be clearer and less confusing as "column dependency"
> already means something else.
>
Actu
On 21 April 2017 at 01:21, Tomas Vondra wrote:
> On 04/21/2017 12:13 AM, Tom Lane wrote:
>>
>> Alvaro Herrera writes:
>>>
>>> Simon just pointed out that having the WITH clause appear in the middle
>>> of the CREATE STATISTICS command looks odd; apparently somebody else
>>> already complained on
On 11 February 2017 at 01:17, Tomas Vondra wrote:
> Thanks for the feedback, I'll fix this. I've allowed myself to be a bit
> sloppy because the number of attributes in the statistics is currently
> limited to 8, so the overflows are currently not an issue. But it doesn't
> hurt to make it future-
On 8 February 2017 at 16:09, David Fetter wrote:
> Combinations are n!/(k! * (n-k)!), so computing those is more
> along the lines of:
>
> unsigned long long
> choose(unsigned long long n, unsigned long long k) {
> if (k > n) {
> return 0;
> }
> unsigned long long r = 1;
>
On 6 February 2017 at 21:26, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>> On 02/01/2017 11:52 PM, Alvaro Herrera wrote:
>
>> > Nearby, some auxiliary functions such as n_choose_k and
>> > num_combinations are not documented. What it is that they do? I'd
>> > move these at the end of the file, ke
On 29 December 2016 at 15:55, Tom Lane wrote:
> Dean Rasheed writes:
>> On 28 December 2016 at 19:12, Tom Lane wrote:
>>> [ getting back to this patch finally... ] I made the suggested change
>>> to that test case, and what I see is a whole lot of "NOTICE: snoop
On 28 December 2016 at 19:12, Tom Lane wrote:
> Stephen Frost writes:
>> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>>> Hmm. I've not read any of the new code yet, but the fact that this
>>> test now reduces to a one-time filter makes it effectively useless
On 17 December 2016 at 15:42, Dean Rasheed wrote:
> It seems that there is a bug in CREATE OR REPLACE VIEW...
>
> DefineView()/DefineVirtualRelation() will need a little re-jigging to
> do things in the required order.
...and the required order for existing views is
1. Add any n
It seems that there is a bug in CREATE OR REPLACE VIEW's handling of
WITH CHECK OPTION (noticed while thinking about the recent change to
pg_dump's handling of circular dependencies in views -- d8c05af). If
you use CREATE OR REPLACE VIEW on a view that isn't auto-updatable and
turn it into one that
Stephen,
I looked through this in a little more detail and I found one other
issue: the documentation for the system catalog table pg_policy and
the view pg_policies needs to be updated to include the new columns
that have been added.
Other than that, it all looks good to me, subject to the previ
On 1 December 2016 at 14:38, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> In get_policies_for_relation() ...
>> ... I think it should sort the restrictive policies by name
>
> Hmmm, is it really the case that the quals will always end up bein
On 30 November 2016 at 21:54, Stephen Frost wrote:
> Unless there's further comments, I'll plan to push this sometime
> tomorrow.
>
Sorry I didn't have time to look at this properly. I was intending to,
but my day job just keeps getting in the way. I do have a couple of
comments relating to the d
On 28 November 2016 at 23:55, Stephen Frost wrote:
>> diff --git a/src/test/regress/expected/updatable_views.out
>> b/src/test/regress/expected/updatable_views.out
> [...]
>> --- 2104,2114
>>
>> EXPLAIN (VERBOSE, COSTS OFF)
>> UPDATE v1 SET a=100 WHERE snoop(a) AND leakproof(a) AND a = 3
On 10 November 2016 at 17:12, Tom Lane wrote:
> Yeah, I think we'd be best off to avoid the bare term "security".
> It's probably too late to change the RTE field name "securityQuals",
> but maybe we could uniformly call those "security barrier quals" in
> the comments. Then the basic terminology
On 8 November 2016 at 16:46, Robert Haas wrote:
> On Thu, Nov 3, 2016 at 6:23 PM, Tom Lane wrote:
>>> I think that ordering might be sub-optimal if you had a mix of
>>> leakproof quals and security quals and the cost of some security quals
>>> were significantly higher than the cost of some other
On 8 November 2016 at 14:45, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> * Since the planner is now depending on Query.hasRowSecurity to be set
>>> whenever there are any securityQuals, I put in an Assert about that,
>>> and promptly found three places in
On 25 October 2016 at 22:58, Tom Lane wrote:
> The alternative I'm now thinking about pursuing is to get rid of the
> conversion of RLS quals to subqueries. Instead, we can label individual
> qual clauses with security precedence markings. Concretely, suppose we
> add an "int security_level" fie
On 4 October 2016 at 09:15, Heikki Linnakangas wrote:
> However, for tables and views, each object you store in those views is a
> "table" or "view", but with this thing, the object you store is
> "statistics". Would you have a catalog table called "pg_scissor"?
>
No, probably not (unless it was
On 30 September 2016 at 12:10, Heikki Linnakangas wrote:
> I fear that using "statistics" as the name of the new object might get a bit
> awkward. "statistics" is a plural, but we use it as the name of a single
> object, like "pants" or "scissors". Not sure I have any better ideas though.
> "estim
On 4 October 2016 at 04:25, Michael Paquier wrote:
> OK. A second thing was related to the use of schemas in the new system
> catalogs. As mentioned in [1], those could be removed.
> [1]:
> https://www.postgresql.org/message-id/cab7npqtu40q5_nsghvomjfbyh1hdtqmbfdj+kwfjspam35b...@mail.gmail.com.
>
On 3 August 2016 at 02:58, Tomas Vondra wrote:
> Attached is v19 of the "multivariate stats" patch series
Hi,
I started looking at this - just at a very high level - I've not read
much of the detail yet, but here are some initial review comments.
I think the overall infrastructure approach for
[Please reply to the list, not just to me, so that others can benefit
from and contribute to the discussion]
On 31 August 2016 at 11:52, Andrea Adami wrote:
> Thnaks Dean, i did further investigations:
> i set the owner of the view to: "mana...@scuola247.it" with:
> ALTER TABLE public.policy_view
On 28 August 2016 at 21:23, Joe Conway wrote:
> Apologies for the delay, but new patch attached. Assuming no more
> comments, will commit this, backpatched to 9.5, in a day or two.
>
Looking at this again, I think there is something fishy about these
dump/restore flags.
If you do pg_dump --enabl
On 20 August 2016 at 03:15, Andrea Adami wrote:
> when i run the query: "select * from public.policy_view"
> the ouput is the same (all rows) for all users
> i'm doing some mistakes or this is a bug ?
>
No, it looks correct to me. When going through a view, the policies
and permission checks tha
On 5 August 2016 at 21:48, Tom Lane wrote:
> OK, thanks. What shall we do about Andreas' request to back-patch this?
> I'm personally willing to do it, but there is the old bugaboo of "maybe
> it will destabilize a plan that someone is happy with".
>
My inclination would be to back-patch it beca
On 1 August 2016 at 08:19, Greg Stark wrote:
> Surely combining multiple hashes is the same problem as hashing a block of
> memory? Shouldn't we just use the same algorithm as hash_any()?
>
Yes, I imagine that should work well. I suspect that Thomas's proposal
would also probably work well, as wo
On 27 July 2016 at 10:17, Andrew Borodin wrote:
>> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX
> / NBASE for any NBASE > 1
Interesting. I think it's clearer the way it is in mul_var() though,
because the
On 27 July 2016 at 09:57, Dean Rasheed wrote:
> it could be
> coded using something like
>
> accum->maxdig += NBASE - 1;
> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1))
> Propagate carries...
>
Oops, that's not quite right becau
On 27 July 2016 at 07:33, Andrew Borodin wrote:
>>I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
>
> I feel that I have to elaborate a bit. Probably my calculations are wrong.
>
> Lets assume we already have accumulated INT_MAX of digits in
> previous-place accum
On 30 May 2016 at 15:44, Andrew Gierth wrote:
>>>>>> "Dean" == Dean Rasheed writes:
>
> Dean> That may be so, but we already support FILTER for all windows
> Dean> functions as well as aggregates:
>
> Not so:
>
> "If FILTER is speci
On 23 May 2016 at 17:01, Jeff Davis wrote:
> On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
> wrote:
>> How does the relatively new FILTER clause play into this, if at all?
>
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RESPECT NULLS
On 25 May 2016 at 02:04, Joe Conway wrote:
> Please see attached two proposed patches for the docs related to RLS:
>
> 1) Correction to pg_restore
> 2) Additional mentions that "COPY FROM" does not allow RLS to be enabled
>
> Comments?
>
The pg_restore change looks good -- that was clearly wrong.
On 4 May 2016 at 13:23, Peter Eisentraut
wrote:
> On 5/4/16 3:21 AM, Dean Rasheed wrote:
>> Well, appendStringLiteralAH() takes both, so that sets a precedent.
> Works for me. Could you supply an updated patch with a static function
> instead of a macro? Then I think thi
On 2 May 2016 at 18:38, Tom Lane wrote:
> I don't much care for the hardwired magic number here, especially since
> exp_var() does not have its limit expressed as "6000" but as
> "NUMERIC_MAX_RESULT_SCALE * 3". I think you should rephrase the limit
> to use that expression, and also add something
On 4 May 2016 at 01:35, Peter Eisentraut
wrote:
> On 5/3/16 3:10 PM, Dean Rasheed wrote:
>> On 3 May 2016 at 16:52, Peter Eisentraut
>>>
>>> I would change appendReloptionsArrayAH() to a function and keep AH as the
>>> first argument (similar to other functio
On 3 May 2016 at 16:52, Peter Eisentraut
wrote:
> I would change appendReloptionsArrayAH() to a function and keep AH as the
> first argument (similar to other functions that take such a handle).
I can understand changing it to a function, but I don't think AH
should be the first argument. All oth
On 2 May 2016 at 19:40, Robert Haas wrote:
> On Mon, May 2, 2016 at 1:02 PM, Dean Rasheed wrote:
>> Doing some more testing of the numeric code patched in [1] I noticed
>> another case where the result is inaccurate -- computing 0.12 ^
>> -2345.6 gives a very large number c
Doing some more testing of the numeric code patched in [1] I noticed
another case where the result is inaccurate -- computing 0.12 ^
-2345.6 gives a very large number containing 2162 digits, but only the
first 2006 correct, while the last 156 digits are wrong.
The reason is this code in power_var(
On 27 April 2016 at 08:36, Dean Rasheed wrote:
> Here is a rough patch based on the way pg_dump handles this. It still
> needs a bit of polishing -- in particular I think fmtReloptionsArray()
> (copied from pg_dump) should probably be moved to string_utils.c so
> that it can be sh
[Looking back over old threads]
On 22 July 2015 at 22:00, Dean Rasheed wrote:
> This appears to be missing support for view options (WITH CHECK OPTION
> and security_barrier), so editing a view with either of those options
> will cause them to be stripped off.
It seems like this issue
On 26 April 2016 at 16:26, Tom Lane wrote:
> The next time somebody proposes that we can get exact results out of
> floating-point arithmetic, I'm going to run away screaming.
>
Yeah, I think I will have the same reaction.
Thanks for all your hard work getting this to work.
Regards,
Dean
--
On 26 April 2016 at 04:48, Andres Freund wrote:
> No, I think we got to do this in all branches. I was just wondering
> about how to fix vm_extend(). Which I do think we got to fix, even in
> the back-branches.
>
I think replacing CacheInvalidateSmgr() with CacheInvalidateRelcache()
in vm_extend(
On 26 April 2016 at 04:25, Tom Lane wrote:
> In short, these tests suggest that we need a coding pattern like
> this:
>
> volatile float8 asin_x = asin(x);
> return (asin_x / asin_0_5) * 30.0;
>
> We could drop the "volatile" by adopting -ffloat-store, but that
> doesn't seem like
On 19 April 2016 at 14:38, Tom Lane wrote:
> Yeah, what I was thinking of printing is something like
>
> asind(x),
> asind(x) IN (-90,-30,0,30,90) AS asind_exact,
> ...
>
> with extra_float_digits=3. The point of this is not necessarily to give
> any extra information, tho
On 19 April 2016 at 05:16, Noah Misch wrote:
> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
>> >> We could alternatively set extra_float_digits to its max value and hope
>> >> that off-by-one-in-the-
On 31 March 2016 at 22:02, Tom Lane wrote:
> I'm just concerned about what happens when the Dellera paper stops being
> available. I don't mind including that URL as a backup to the written-out
> argument I just suggested.
>
Here's an updated patch with references to both papers, and a more
deta
On 31 March 2016 at 21:40, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Another minor gripe is the use of a random URL as justification. This
>>> code will still be around when that URL exists nowhere but the Wayback
>>> Machine. Can't we find a more formal citation to use?
>
On 31 March 2016 at 20:18, Tom Lane wrote:
> Also, I wonder if it'd be a good idea to provide a guard against division
> by zero --- we know rel->tuples > 0 at this point, but I'm less sure that
> reldistinct can't be zero. In the same vein, I'm worried about the first
> argument of pow() being s
On 30 March 2016 at 14:03, Tomas Vondra wrote:
> Attached is v4 of the patch
Thanks, I think this is good to go, except that I think we need to use
pow() rather than powl() because AIUI powl() is new to C99, and so
won't necessarily be available on all supported platforms. I don't
think we need w
On 16 March 2016 at 23:32, David Steele wrote:
> On 3/10/16 1:24 PM, Corey Huinker wrote:
>
>> New patch for Alvaro's consideration.
>>
>> Very minor changes since the last time, the explanations below are
>> literally longer than the changes:
>> - Rebased, though I don't think any
On 18 March 2016 at 00:37, Tomas Vondra wrote:
>> On Sun, 2016-03-13 at 15:24 +, Dean Rasheed wrote:
>>> I think that a better formula to use would be
>>>
>>> reldistinct *= (1 - powl(1 - rel-rows / rel->tuples, rel->tuples /
>>> reldistin
On 4 March 2016 at 13:10, Tomas Vondra wrote:
> The risk associated with over-estimation is that we may switch from
> HashAggregate to GroupAggregate, and generally select paths better
> suited for large number of rows. Not great, because the plan may not be
> optimal and thus run much slower - bu
On 18 February 2016 at 10:05, Dean Rasheed wrote:
> OK, I'll add a check for that.
> Thanks for testing.
>
Pushed, with a catversion bump.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On 18 February 2016 at 02:00, Vitaly Burovoy wrote:
>> + else
>> + have_digits = false;
> Does it worth to move it to the declaration and remove that "else" block?
> + boolhave_digits = false;
OK, that's probably a bit neater.
> Is it important to use:
>> + Ob
On 17 February 2016 at 02:32, Jim Nasby wrote:
> On 2/11/16 4:21 AM, Dean Rasheed wrote:
>>
>> Thinking about this some more though, perhaps*sorting* the columns is
>> the wrong way to be thinking about it. Perhaps a better approach would
>> be to allow the columns
On 15 February 2016 at 14:08, Daniel Verite wrote:
> Dean Rasheed wrote:
>
>> My biggest problem is with the sorting, for all the reasons discussed
>> above. There is absolutely no reason for \crosstabview to be
>> re-sorting rows -- they should just be le
On 17 February 2016 at 00:39, Vitaly Burovoy wrote:
> On 2/16/16, Vitaly Burovoy wrote:
>> On 2/16/16, Dean Rasheed wrote:
>>> Fixing that in parse_memory_unit() would be messy because it assumes a
>>> base unit of kB, so it would require a negative multiplier, an
On 16 February 2016 at 05:01, Pavel Stehule wrote:
> 2016-02-15 10:16 GMT+01:00 Dean Rasheed :
>> Is there any reason not to make
>> pg_size_bytes() return numeric?
>>
> This is a question. I have not a strong opinion about it. There are no any
> technical objection -
> On 12/02/16 10:19, Dean Rasheed wrote:
>> This seems like a reasonable first patch for me as a committer, so
>> I'll take it unless anyone else was planning to do so.
>
So looking at this, it seems that for the most part pg_size_bytes()
will parse any output produced b
On 12 February 2016 at 06:25, Pavel Stehule wrote:
> Thank you for review and other work
>
This seems like a reasonable first patch for me as a committer, so
I'll take it unless anyone else was planning to do so.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On 11 February 2016 at 13:18, Robert Haas wrote:
> On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote:
>> As it currently stands, max_parallel_degree is set to a superuser
>> context
>
> I don't have a clue why it's like that. It seems like it should be
> PGC_USERSSET just like, say, work_mem. I
1 - 100 of 616 matches
Mail list logo