On Sat, May 30, 2015 at 11:10 AM, Robert Haas robertmh...@gmail.com wrote:
Let me share something that people have told me privately but don't want
to state publicly (at least with attribution), and that is that we have
seen great increases in feature development (often funded), without a
On Sat, May 30, 2015 at 5:56 AM, Bruce Momjian br...@momjian.us wrote:
Frankly, based on how I feel now, I would have no problem doing 9.5 in
2016 and saying we have a lot of retooling to do. We could say we have
gotten too far out ahead of ourselves and we need to regroup and
restructure the
Hi Bruce, Everyone,
On 2015-05-30 11:45:59 -0400, Bruce Momjian wrote:
Let me share something that people have told me privately but don't want
to state publicly (at least with attribution), and that is that we have
seen great increases in feature development (often funded), without a
On 2015-05-30 14:10:36 -0400, Robert Haas wrote:
It's clear - at least to me - that we need to put more resources into
stabilizing the new multixact system. This is killing us. If we can't
stabilize this, people will go use some other database.
I agree. Perhaps I don't see things quite as
Tomas Vondra tomas.von...@2ndquadrant.com writes:
I wonder whether the
run_cost += inner_run_cost;
is actually correct, because this pretty much means we assume scanning
the whole inner relation (once). Wouldn't something like this be more
appropriate?
run_cost +=
Andres Freund and...@anarazel.de writes:
* The signal handling, sinval, client communication changes. Little to
none problems so far, but it's complex stuff. These changes are an
example of potential for problems due to changes to reduce
complexity...
As far as that goes, it's quite
Hi,
On 05/30/15 04:41, Andres Freund wrote:
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in
On 05/30/15 03:52, Tomas Vondra wrote:
On 05/30/15 01:20, Tomas Vondra wrote:
Notice the cost - it's way lover than the previous plan (9.2 vs
~111k), yet this plan was not chosen. So either the change broke
something (e.g. by violating some optimizer assumption), or maybe
there's a bug
On Sat, May 30, 2015 at 11:45 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, May 30, 2015 at 10:06:52AM -0400, Robert Haas wrote:
If that means it's stable, +1 from me.
I dispute, on every level, the notion that not releasing a beta means
that we can't work on things in parallel. We can
On 05/30/15 16:47, Tom Lane wrote:
Another reason why that would be a bad place is that a pg_class update
forces relcache invalidation and thereby cached-plan invalidation.
You don't want that for anything except (1) DDL affecting the table or
(2) change in statistics that affect plan
I wrote:
So what this seems to mean is that for SEMI/ANTI join cases, we have to
postpone all of the inner scan cost determination to final_cost_nestloop,
so that we can do this differently depending on whether
has_indexed_join_quals() is true. That's a little bit annoying because it
will
On 05/30/15 21:50, Tom Lane wrote:
So what this seems to mean is that for SEMI/ANTI join cases, we have
to postpone all of the inner scan cost determination to
final_cost_nestloop, so that we can do this differently depending on
whether has_indexed_join_quals() is true. That's a little bit
On Sat, May 30, 2015 at 3:12 PM, Peter Geoghegan p...@heroku.com wrote:
Debugging this allowed me to come up with a significantly simplified
approach. Attached is a new version of the original fix. Details are
in commit message -- there is no actual need to have
search_indexed_tlist_for_var()
On May 30, 2015 2:19:00 PM PDT, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
* The signal handling, sinval, client communication changes. Little
to
none problems so far, but it's complex stuff. These changes are an
example of potential for problems due to
On Sat, May 30, 2015 at 1:07 AM, Peter Geoghegan p...@heroku.com wrote:
My fix for this issue
(0001-Fix-bug-with-whole-row-Vars-in-excluded-targetlist.patch) still
missed something. There needs to be additional handling in
ruleutils.c:
Debugging this allowed me to come up with a significantly
Hi,
On 05/30/15 23:16, Tom Lane wrote:
I wrote:
So what this seems to mean is that for SEMI/ANTI join cases, we have to
postpone all of the inner scan cost determination to final_cost_nestloop,
so that we can do this differently depending on whether
has_indexed_join_quals() is true. That's a
On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao
On Sat, May 30, 2015 at 11:47 AM, Peter Eisentraut pete...@gmx.net wrote:
It appears to be an omission that ALTER TABLE ... ENABLE TRIGGER and
similar commands don't allow acting on views, even though we now have
triggers on views.
True, now isn't it something that should be as well part of
On Fri, May 29, 2015 at 04:01:00PM -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Bruce Momjian (br...@momjian.us) wrote:
I am unclear if we are anywhere near ready for beta1 even in June. Are
we?
I'm all about having that discussion... but can we do it on another
On Thu, May 28, 2015 at 2:37 PM, Peter Geoghegan p...@heroku.com wrote:
Attached, revised version incorporates this small fix, while adding an
additional big fix, and a number of small style tweaks.
This is mainly concerned with fixing the bug I was trying to fix when
I spotted the minor
On Sat, May 30, 2015 at 6:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I noticed that if you use initdb -S, the code does its thing and
exits without ever calling get_restricted_token(). It doesn't get
to get_id() where the no-superuser check is, either. Is this OK,
or should we reorder the
Re: Michael Paquier 2015-05-28
CAB7nPqSOx2TEgsypk8gbfa=_hjn7wnlf_trzexy+snn3fvf...@mail.gmail.com
Attached is a doc patch among those lines.
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 89a609f..6485b42 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
On Sat, May 30, 2015 at 12:08:07AM -0400, Tom Lane wrote:
desperately in need of testing. The custom-plan code is desperately
in need of fixing and testing. The multixact code is desperately
in need of testing. The open-items list has several other problems
besides those. All of those
On Sat, May 30, 2015 at 08:56:53AM -0400, Bruce Momjian wrote:
On Sat, May 30, 2015 at 12:08:07AM -0400, Tom Lane wrote:
desperately in need of testing. The custom-plan code is desperately
in need of fixing and testing. The multixact code is desperately
in need of testing. The open-items
On Sat, May 30, 2015 at 12:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think your position is completely nuts. The GROUPING SETS code is
desperately in need of testing. The custom-plan code is desperately
in need of fixing and testing. The multixact code is desperately
in need of testing.
On 05/30/2015 06:11 AM, Bruce Momjian wrote:
2017? Really? Is there any need for that hyperbole?
Frankly, based on how I feel now, I would have no problem doing 9.5 in
2016 and saying we have a lot of retooling to do. We could say we have
gotten too far out ahead of ourselves and we need
Andres Freund and...@anarazel.de writes:
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in pg_class;
On Sat, May 30, 2015 at 10:06:52AM -0400, Robert Haas wrote:
If that means it's stable, +1 from me.
I dispute, on every level, the notion that not releasing a beta means
that we can't work on things in parallel. We can work on all of the
things on the open items list in parallel right now.
28 matches
Mail list logo
