On 9 July 2014 09:27, Tom Lane wrote:
> David Rowley writes:
> > On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane wrote:
> >> I'm a bit skeptical as to whether testing for that case is actually
> worth
> >> any extra complexity. Do you have a compelling use-case?
On Wed, Jul 9, 2014 at 12:59 PM, Tom Lane wrote:
> David Rowley writes:
> > On 9 July 2014 09:27, Tom Lane wrote:
> >> On review it looks like analyzejoins.c would possibly benefit from an
> >> earlier fast-path check as well.
>
> > Do you mean for non-sub
the join condition to prove not null-ability.
I'll try and get some time soon to look into adding the IS NOT NULL quals,
unless you were thinking of looking again?
Regards
David Rowley
> Of course this would require x/y not being volatile, but if they are,
> we're not going to get far with optimizing the query anyhow.
>
> regards, tom lane
>
the join condition if the right side of
the join had no tuples... Of course I'm not suggesting it gets implemented
this way, I'm just otherwise out of ideas.
Regards
David Rowley
On Mon, Jul 14, 2014 at 3:00 AM, Tom Lane wrote:
> David Rowley writes:
> > I had another look at this and it appears you were right the first time,
> we
> > need to ensure there's no NULLs on both sides of the join condition.
>
> Ugh. I'm back to being disco
On Wed, Jul 16, 2014 at 1:17 PM, Tom Lane wrote:
> David Rowley writes:
> > I've attached an updated patch which puts in some fast path code for
> > subquery type joins. I'm really not too sure on a good name for this
> > function. I've ended up with query_s
On Wed, Jul 16, 2014 at 9:11 AM, Tom Lane wrote:
> Simon Riggs writes:
> > On 15 July 2014 12:58, David Rowley wrote:
> >> I found that the call to is_NOTANY_compatible_with_antijoin adds about
> 0.2%
> >> and 2.3% to total planning time. Though the 2.3% was qui
e isolation tests part does not
seem to apply at all now, so I've not managed to look at those yet.
I've still got more to look at, but hopefully this will get things moving
again.
Regards
David Rowley
it a try if required.
In order to get my patch working with an Assert enabled build I've had to
apply the attached patch.
Regards
David Rowley
get_loop_count_ignore_dead_rels.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Sat, Jul 26, 2014 at 9:11 PM, David Rowley wrote:
> In order to get my patch working with an Assert enabled build I've had to
> apply the attached patch.
>
Actually I meant to attach this patch instead.
Regards
David Rowley
get_loop_count_ignore_dead_rels_v2.patch
Descr
s then maybe this would be a
good time to invent somewhere.
Maybe someone with more experience can chime in and give advice on this?
Regards
David Rowley
On Sun, Jul 27, 2014 at 2:35 AM, Tom Lane wrote:
> David Rowley writes:
> > In order to get my patch working with an Assert enabled build I've had to
> > apply the attached patch.
>
> That patch is entirely bogus. What you should be asking is why
> get_loop_count i
;m wondering if it would be ok just to
replace the test with an Assert() instead, or maybe just no check.
Also, I'm just looking at some of the changes that you've done to function
signatures... I see quite a few of them are now beyond 80 chars wide (see
http://www.postgresql.org/docs/devel/static/source-format.html).
Regards
David Rowley
On Tue, Jul 29, 2014 at 1:35 PM, Alvaro Herrera
wrote:
> David Rowley wrote:
>
> > I've also been looking at the isolation tests and I see that you've
> added a
> > series of tests for NOWAIT. I was wondering why you did that as that's
> > really existi
the query
then the one with the highest enum value takes precedence over the others.
Apart from this I can't see any other problems with the patch and I'd be
very inclined, once the above are fixed up to mark the patch ready for
commiter.
Good work
Regards
David Rowley
uld fix up all 3 of these locations and stick
that code in a header file, but I don't really know where at the
moment. This at least should get the build running again.
Regards
David Rowley
pgbench_M_PI_fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
On Sat, Aug 2, 2014 at 3:55 AM, Thomas Munro wrote:
> On 1 August 2014 10:37, David Rowley wrote:
> > Apart from this I can't see any other problems with the patch and I'd be
> > very inclined, once the above are fixed up to mark the patch ready for
> > commite
early) for the August commitfest, but if
anyone has any time to glance at it before then then that would be a really
good help.
Regards
David Rowley
semianti_join_removal_2410c7c_2014-08-05.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this altogether, since it's already broken and looks
like it has been for about 11 years
Disallowing it would simplify some code in my semi/anti join removal patch
that I posted here
http://www.postgresql.org/message-id/CAApHDvpCBEfuc5tD=vniepAv0pU5m=q=foqzcodmheei7oq...@mail.gmail.com
Any
ve the code which disallows the duplicate
column references could likely do with some meaningful explanation about
the reasons why we disallow these, I thought your words would be a bit
better at doing this so I didn't try very hard on that part.
Is this roughly what you had in mind?
Regards
On Sat, Aug 9, 2014 at 3:34 PM, Tom Lane wrote:
> David Rowley writes:
> > On Sat, Aug 9, 2014 at 12:13 PM, Tom Lane wrote:
> >> So I'm thinking you're right: we should rewrite this code so that only
> >> indexes having all columns distinct can match, there
On Tue, Aug 5, 2014 at 10:35 PM, David Rowley wrote:
>
> The patch (attached) is also now able to detect when a NOT EXISTS clause
> cannot produce any records at all.
>
>
I've attached an updated version of the patch which fixes up some
incorrect logic in the foreign key
On Wed, Aug 13, 2014 at 3:19 PM, Noah Misch wrote:
> On Sat, Nov 16, 2013 at 12:53:10PM +1300, David Rowley wrote:
> > I went on a bit of a strncpy cleanup rampage this morning and ended up
> > finding quite a few places where strncpy is used wrongly.
> > I'm not qui
ity problems go, this one
> has
> been minor.
>
>
Or maybe it would be better to just remove the restriction and just palloc
something of the correct size?
Although, that sounds like a much larger patch. I'd vote that the strlcpy
should be used in the meantime.
Regards
David Rowley
On Sun, Aug 10, 2014 at 11:48 PM, David Rowley wrote:
>
> I've attached an updated version of the patch which fixes up some
> incorrect logic in the foreign key matching code, plus various comment
> improvements.
>
I've made a few updated to the patch to simplify som
tuples / DEFAULT_NUM_DISTINCT)
That's all I have at the moment... More to follow soon.
Regards
David Rowley
partial-sort-basic-1_rebased.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> very much incomplete like this has a chance to get committed.
I do strongly agree that the estimates need improved here. I've
personally had issues with bad brin estimates before, and I'd like to
see it improved. I think the patch is not quite complete without it
also consideri
On 22 March 2017 at 22:27, Simon Riggs wrote:
> On 20 March 2017 at 08:31, David Rowley wrote:
>> 0003:
>>
>> Is intended to be patched atop of 0002 (for master only) and revises
>> this code further to remove the StandbyReleaseLockTree() function. To
>> me it se
to v11 will get all types, if they did in v10,
and the same subset that they did in v10 when only a subset were
originally defined.
Since we support only 1 type now, nothing needs to happen there yet.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Developmen
Probably there's more that can be done here. I see GatherState has
nreaders too, but I've not looked into the detail of if it suffers
from the same weirdness of nreaders always matching nworkers_launched.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Devel
alue like -1 could be used for this... unsure of
how that would be documented though...
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 26 March 2017 at 00:17, Amit Kapila wrote:
> On Sat, Mar 25, 2017 at 6:31 PM, David Rowley
> wrote:
>> On 25 March 2017 at 23:09, Rushabh Lathia wrote:
>>> Also another point which I think we should fix is, when someone set
>>> max_parallel_worke
On 14 March 2017 at 16:37, David Rowley wrote:
> On 14 March 2017 at 11:35, David Rowley
> wrote:
>>
>> On 14 March 2017 at 07:50, Tom Lane wrote:
>>>
>>> [ getting back to this patch finally... ]
>>>
>>> David Rowley writes:
>>>
_PARALLEL_OFF && best_path->parallel_safe)
{
Gather *gather = makeNode(Gather);
Probably force_parallel_mode is good for testing the tuple queue code,
and some code in Gather, but I'm not quite sure what else its good
for. Certainly not GatherMerge.
--
David Rowley
On 27 March 2017 at 09:28, David Rowley wrote:
> Patch is attached which fixes up the conflict between the expression
> evaluation performance patch.
Seems I forgot to commit locally before creating the patch... Here's
the actual patch I meant to attach earlier.
--
D
gt; should be less then the nreaders + 1 (leader).
>
> Well, you and David Rowley seem to disagree on what the fix is here.
> His patches posted upthread do A, and yours do B, and from a quick
> look those things are not just different ways of spelling the same
> underlying fix, but actually
should work exactly.
I've attached a patch which fixes the problem above, but it does
nothing to change the analyze behaviour for 0 statistics columns.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
stats_ex
that couldn't use any extended stats. I'm planning on having a bit more of
a look at this tomorrow.
The attached patch should apply to master as
of f90d23d0c51895e0d7db7910538e85d3d38691f0.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
M public.ft_t
(lots of these)
select count(*) from pg_stat_Activity; --> 105
I've not had a moment to check into what's going on.
Adding to open items...
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 31 March 2017 at 16:32, Etsuro Fujita
wrote:
> On 2017/03/31 8:28, David Rowley wrote:
>
>> create table t (a int, b int);
>> insert into t1 select x/100,x/100 from generate_series(1,10) x;
>> create extension if not exists postgres_fdw;
>> create server te
On 31 March 2017 at 21:18, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello,
>
> At Fri, 31 Mar 2017 03:03:06 +1300, David Rowley <
> david.row...@2ndquadrant.com> wrote in T5JLce5ynCi1vvezXxX=w...@mail.gmail.com>
>
> FWIW, I tries this. Th
onditions are compatible with
> all statistics */
> + break;
> +
> + default:
> +
> + /* unknown estimator */
> + return true;
> + }
>
> This seems
On 27 March 2017 at 15:51, David Rowley
wrote:
> On 27 March 2017 at 09:28, David Rowley
> wrote:
>
> > Patch is attached which fixes up the conflict between the expression
> > evaluation performance patch.
>
> Seems I forgot to commit locally before creating the p
On 2 April 2017 at 21:21, David Rowley wrote:
> I've attached an updated patch which updates the regression test output of
> a recent commit to include the "Unique Inner" in the expected results.
>
The patch must've fallen off. Attempt number 2 at
ogical and
Can you explain why this is the case?
+ * class "minmax", and makes a little sense for the other one "inclusion".
"and" I think should be "but"
I think it would also be good to write some regression tests for this. All
the chang
name of
the Var in the new CachedSelectivityClause struct. It seems like a
change not related to this patch.
Do you think I should change that too?
>
> On Fri, Feb 24, 2017 at 7:00 AM, David Rowley
> wrote:
> > Now one thing I was unsure of in the patch was this "Other clauses&qu
On 4 April 2017 at 08:24, Andres Freund wrote:
> On 2017-04-03 20:59:42 +1200, David Rowley wrote:
>> Updated patch attached.
>>
>> Thanks for reviewing it.
>
> Given the time in the release cycle I'm afraid that this it's too late
> to get this into
on a IS NOT NULL test
to exists to estimate that properly. I don't think that needs done as
part of this patch. I'd rather limit the scope since "returned with
feedback" is already knocking at the door of this patch.
--
David Rowley http://www.2ndQuadrant
On 1 April 2017 at 04:25, David Rowley wrote:
> I've attached an updated patch.
I've made another pass at this and ended up removing the tryextstats
variable. We now only try to use extended statistics when
clauselist_selectivity() is given a valid RelOptInfo with rtekind ==
RTE_REL
is needed as the attached.
Thanks for writing the patch.
I wondering if it would be worth simplifying it a little to get rid of
the double #ifdefs, as per attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 4 April 2017 at 13:35, Claudio Freire wrote:
> On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote:
>> On Mon, Apr 3, 2017 at 8:52 PM, David Rowley
>> wrote:
>>>> One last observation:
>>>>
>>>> +/*
>>>> +
On 3 April 2017 at 20:59, David Rowley wrote:
> Updated patch attached.
I did a little benchmarking on this to learn how planning time is affected.
Master = 9fa6e08d4a16f9b0461743cff35781e16308c106
Patched = 9fa6e08d4a16f9b0461743cff35781e16308c106 +
smarter_clausesel_2017-04-03.patch
Con
ating > 100% of the table.
I was a bit worried that Emre's method would penalise BRIN too much
when the correlation is not so high.
Interested to hear comments on this.
Please feel free to play with the spreadsheet by changing rows 1-3 in column B.
--
David Rowley http
> Still in dependencies_clauselist_selectivity,
> dependency_implies_attributes seems designed to return true for
> at least one clause in the clauses but any failure leands to
> infinite loop. I think any measure against the case is required.
I did consider this, but I really can
essage-id/CAEZATCUtGR+U5+QTwjHhe9rLG2nguEysHQ5NaqcK=vbj78v...@mail.gmail.com
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6 April 2017 at 10:17, Simon Riggs wrote:
> On 5 April 2017 at 10:47, David Rowley wrote:
>
>> I've attached an updated patch to address Tomas' concerns and yours too.
>
> Commited, with some doc changes and additions based upon my explorations.
Great. Thanks
function being called 72 times in a 5 way join
search problem.
Perhaps there is a nicer way to do this, I just couldn't think of it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers maili
On 6 April 2017 at 11:33, Tom Lane wrote:
> David Rowley writes:
>> On 6 April 2017 at 10:48, Tom Lane wrote:
>>> The buildfarm is unhappy about the fact that this changed the API
>>> for clauselist_selectivity(). I am not convinced that that change
>>> wa
On 6 April 2017 at 13:05, David Rowley wrote:
> I tested with the attached, and it does not seem to hurt planner
> performance executing:
Here's it again, this time with a comment on the
find_relation_from_clauses() function.
--
David Rowley http://www.2ndQ
do still have concerns about how the correlation value is used, and
the fact that we use the highest value, but then the whole use of this
value is far from perfect, and is just a rough indication of how
things are.
Apart from that, I'm pretty happy with this now.
--
David Rowley
On 6 April 2017 at 18:03, Kyotaro HORIGUCHI
wrote:
> At Thu, 6 Apr 2017 13:10:48 +1200, David Rowley
> wrote in
>
>> On 6 April 2017 at 13:05, David Rowley wrote:
>> > I tested with the attached, and it does not seem to hurt planner
>> > performance execu
On 6 April 2017 at 19:50, Kyotaro HORIGUCHI
wrote:
> At Thu, 6 Apr 2017 18:59:35 +1200, David Rowley
> wrote in
>
>> On 6 April 2017 at 18:03, Kyotaro HORIGUCHI
>> wrote:
>> > At Thu, 6 Apr 2017 13:10:48 +1200, David Rowley
>> > wrote in
>> &g
er it seems to be copied from
>> btcostestimate(), which also seems to be a long-standing bug
>> introduced in a536ed53bca40cb0d199824e358a86fcfd5db7f2. I'll go write
>> a patch for that one now.
>
>
> Yes, I copy-pasted from btcostestimate().
Turns out it's no
on that only one rel's extended stats will
>> ever be of interest? This function does get used for join clauses.
>
> Point noted. Reading thread and hope to fix today.
I've attached a rebased patch which fixes up the conflict with the
BRIN cost estimate patch which wen
n, and compute_semijoin_info() seems to take all of the join
conditions there or nothing at all, so I think it's safe to
automatically mark JOIN_UNIQUE_INNERs this way.
Updated patch is attached.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Developm
ullfrac separately, so the nullfrac could just be
>>> applied once per expression. There's already hacks in there to get rid
>>> of the double null filtering. I'm not proposing that as something for
>>> this patch. It would be pretty invasive to change this.
>&g
On 7 April 2017 at 11:47, Tom Lane wrote:
> David Rowley writes:
>> On 7 April 2017 at 07:26, Tom Lane wrote:
>>> I'm looking through this, and I'm failing to see where it deals with
>>> the problem we discussed last time, namely that you can't apply th
On 7 April 2017 at 13:41, Tom Lane wrote:
> David Rowley writes:
>> On 7 April 2017 at 11:47, Tom Lane wrote:
>>> What I'm on about is that you can't do the early advance to the
>>> next outer tuple unless you're sure that all the quals that were
>
gt; Therefore I propose changing the defaults in pg_regress.c.
You mean people actually use those diffs? I've never done anything
apart from using . That way I can
reject and accept the changes as I wish, just by kicking the results
over to the expected results, or not, if there's a genui
idth=4) (actual
time=0.903..0.903 rows=0 loops=1)
Filter: ((value >= 101) AND (value <= '-1'::integer))
Rows Removed by Filter: 10000
Planning time: 0.162 ms
Execution time: 0.925 ms
(5 rows)
Which comes from the 1 * 0.005 selectivity estimate from tuples *
DEFAULT_RAN
On 8 April 2017 at 14:23, Tom Lane wrote:
> David Rowley writes:
> [ unique_joins_2017-04-07b.patch ]
>
> It turned out that this patch wasn't as close to committable as I'd
> thought, but after a full day of whacking at it, I got to a place
> where I thought it was O
eric way of solving this
which I'd like to take care of in PG11.
Many thanks for your reviews and suggestions on this patch, it's much
appreciated.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via
s used after being assigned, whereas,
some other compilers might see the variable as uselessly assigned.
At the moment there are no other warnings from MSVC since all the
other places the variable gets assigned a value in some code path.
--
David Rowley http://www.2ndQuadrant.com/
Po
log | pg_last_wal_replay_location| pg_lsn |
| normal
pg_catalog | pg_wal_location_diff | numeric |
pg_lsn, pg_lsn | normal
(6 rows)
Opinions?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
S
allow anything ANALYZE is allowed on.
The attached does this.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ext_stats_on_analyzable_objects.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (p
value it would add. Maybe we need to discuss this, but in the
meantime, I've attached a patch which just removes the view completely
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
drop_pg_stats_ext_view.pat
should I?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12 April 2017 at 21:45, Ashutosh Bapat
wrote:
> On Wed, Apr 12, 2017 at 12:18 PM, David Rowley
> wrote:
>> On 10 March 2017 at 17:33, Ashutosh Bapat
>> wrote:
>>> Yes and I also forgot to update the function prologue to refer to the
>>> fpinfo_o/i
ind is better.
A patch which changes this is attached
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ext_stats_rename_staenabled.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
y depend on the
shippable_extensions.
Apart from that, it all looks fine to me.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On 18 April 2017 at 09:01, Alvaro Herrera wrote:
> David Rowley wrote:
>> While reviewing extended stats I noticed that it was possible to
>> create extended stats on many object types, including sequences. I
>> mentioned that this should be disallowed. Statistics were then
inal patch and added to it a bit,
but credits don't seem to reflect that. It's not the end of the world
but just wanted to note that.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers
"location" seems to be winning
Is that enough to proceed?
Anyone else?
The patch to do this should likely also include a regression test to
ensure nothing new creeps in which breaks the new standard.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Deve
On 19 April 2017 at 15:31, Tom Lane wrote:
> David Rowley writes:
>> OK, so I've read over this thread again and I think it's time to
>> summarise the votes:
>> ...
>> In favour of "location" -> "lsn": Stephen, David Steel,
>> In
.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
appendStringInfo_fixes.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ith or without the FK. But in some quick testing I could not
> produce a counterexample proving that that heuristic is helpful;
> so for now let's can it.
>
> Thanks, and sorry again for the delay.
Many thanks for taking the time on this.
--
David Rowley http://
On 16 August 2017 at 15:38, Peter Eisentraut
wrote:
> committed
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
cleanup too.
I'll feel better once pademelon goes green again. From looking at the
latest failure on it, it appears that your swapping of
pg_atomic_write_u64 for pg_atomic_init_u64 should fix this. My
apologies for that mistake.
--
David Rowley http://www.2ndQuadrant.
been added in [1]
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a71f10189dc10a2fe422158a2c9409e0f77c6b9e
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsq
t you're
proposing and why it's not any good.
[1]
https://www.postgresql.org/message-id/cakjs1f9hmet+7adiceau8heompob5pkkcvyzliezje3dvut...@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAEZATCUtGR+U5+QTwjHhe9rLG2nguEysHQ5NaqcK=vbj78v...@mail.gmail.com
--
David Rowley
e
to CREATE INDEX
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The attached small patched fixes an incorrect usage of an error code
in the extended stats code.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
ext_stats_duplicate_column_errorcode_fix.patch
Description: Binary
nt when multiplying selectivity estimations for multiple columns.
Unsure how best to trim that down to something short enough for the
release notes.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgs
On 25 April 2017 at 02:15, Tom Lane wrote:
> David Rowley writes:
>> The attached small patched fixes an incorrect usage of an error code
>> in the extended stats code.
>
> Hmm, looks like all of that could do with an editorial pass (e.g.,
> "duplicity" does
ng to 9.6, I came up with the attached reduced version.
> Since we don't have add_foreign_grouping_paths() in 9.6, we can omit the
> refactoring and keep the changes much simpler. Does that make sense?
That makes sense to me. It fixes the reported issue and is less
invasive than the pg10 patch.
--
On 27 April 2017 at 01:31, Peter Eisentraut
wrote:
> committed
Great. Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
dgment and add to the next 'fest.
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 29 April 2017 at 00:45, Alexander Korotkov wrote:
> On default config, after loading example.sql.bz2 and VACUUM ANALYZE, query
> result is OK.
Hi,
Did you mean to attach this?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Tr
o fix the issue.
I don't know yet if that's the correct fix. It's pretty late 'round
this side to be thinking too hard about it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent vi
x27;d be voting for
minimal patch if this was for a minor version release fix, but we're
not even in beta yet for v10. The original patch was intended to fix
cases like this, although I'd failed to realise this particular case.
--
David Rowley http://www.2ndQuadrant.com/
201 - 300 of 915 matches
Mail list logo
