On Sun, Jun 21, 2015 at 5:45 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 21 June 2015 at 05:27, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I propose instead the attached patch, which operates by identifying which
of the
Dean Rasheed dean.a.rash...@gmail.com writes:
However, there's an obvious improvement that can be made to Tom's
patch -- having computed modifiableARIindexes, you may as well use it
in the innermost loop to only apply ChangeVarNodes() to those
AppendRelInfo's that can actually change, rather
On Fri, Jun 19, 2015 at 9:20 AM, Robert Haas robertmh...@gmail.com wrote:
The extraordinarily planning time for query 4 is caused by a
completely different problem: SearchCatCache eats up huge amounts of
CPU; its callers are get_attavgwidth and get_typlen. It's not clear
to me why doubling
Robert Haas robertmh...@gmail.com writes:
Meanwhile, here is an updated patch.
I don't care for that patch too much: it seems a bit brute-force, and I'm
quite worried by the assumption that it's okay to destroy each child's
append_rel_list after processing the child. That would fail if any of
On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Meanwhile, here is an updated patch.
I don't care for that patch too much: it seems a bit brute-force, and I'm
quite worried by the assumption that it's okay to destroy each child's
Petr Jelinek p...@2ndquadrant.com writes:
On 2015-06-19 01:04, Petr Jelinek wrote:
On 2015-06-19 00:38, Petr Jelinek wrote:
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are
obviously broken.
Apparently it's not a good idea to do this at
On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
thomas.mu...@enterprisedb.com wrote:
We saw a rather extreme performance problem in a cluster upgraded from
9.1 to 9.3. It uses a largish number of child tables (partitions)
On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
thomas.mu...@enterprisedb.com wrote:
We saw a rather extreme performance problem in a cluster upgraded from
Dean Rasheed dean.a.rash...@gmail.com writes:
On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote:
I feel I might be missing a trick here. It seems unlikely to me that
we actually need the entire append_rel_list for every subquery; and we
almost certainly don't need to modify
On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote:
I feel I might be missing a trick here. It seems unlikely to me that
we actually need the entire append_rel_list
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a bit surprised that duplicating the append_rel_list is a noticeable
performance problem. It ought to be far smaller than the Query tree that
we've always duplicated in this loop
I wrote:
Robert Haas robertmh...@gmail.com writes:
Well, append_rel_list has an AppendRelInfo for every RTE and that
contains a List (translated_vars) which in turn contains a Var node
for every column. I'm not sure how that compares to the RTE itself.
RTEs also have a per-column component,
On Thu, Jun 18, 2015 at 4:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... although I see that range_table_mutator doesn't bother to copy/change
the column alias substructure. (Wonder if that gives rise to any
observable EXPLAIN bugs...) But it still seems like the append_rel_list
shouldn't be
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are obviously
broken.
Bah, typos. Attached patch corrects them.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff
On 2015-06-19 00:38, Petr Jelinek wrote:
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are obviously
broken.
Bah, typos. Attached patch corrects them.
Actually it should probably look more like this, sorry.
--
Petr Jelinek
On 2015-06-19 01:04, Petr Jelinek wrote:
On 2015-06-19 00:38, Petr Jelinek wrote:
On 2015-06-18 22:04, Tom Lane wrote:
By the by, the tablesample additions to range_table_mutator are
obviously
broken.
Bah, typos. Attached patch corrects them.
Actually it should probably look more like
Hi
We saw a rather extreme performance problem in a cluster upgraded from
9.1 to 9.3. It uses a largish number of child tables (partitions) and
many columns. Planning a simple UPDATE via the base table started
using a very large amount of memory and CPU time.
My colleague Rushabh Lathia
On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
thomas.mu...@enterprisedb.com wrote:
We saw a rather extreme performance problem in a cluster upgraded from
9.1 to 9.3. It uses a largish number of child tables (partitions) and
many columns. Planning a simple UPDATE via the base table started
18 matches
Mail list logo
