Dean Rasheed 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 than having it trawl
>
On Sun, Jun 21, 2015 at 5:45 AM, Dean Rasheed wrote:
> On 21 June 2015 at 05:27, Robert Haas wrote:
>> On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
>>> I propose instead the attached patch, which operates by identifying which
>>> of the append_rel_list entries actually contain subquery refer
On 21 June 2015 at 05:27, Robert Haas wrote:
> On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
>> I propose instead the attached patch, which operates by identifying which
>> of the append_rel_list entries actually contain subquery references, and
>> copying only those; the other ones are just l
On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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
the Vars/subexpression
On Fri, Jun 19, 2015 at 9:20 AM, Robert Haas 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 the number of relati
Petr Jelinek 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 1AM afte
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 th
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-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 --gi
On Thu, Jun 18, 2015 at 4:04 PM, Tom Lane 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 all that much b
I wrote:
> Robert Haas 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, namely the li
Robert Haas writes:
> On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane 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 --- in particular, it's really a
On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> On 18 June 2015 at 14:48, Robert Haas 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
Dean Rasheed writes:
> On 18 June 2015 at 14:48, Robert Haas 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 every element of the
>> append_rel_list f
On 18 June 2015 at 14:48, Robert Haas wrote:
> On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas wrote:
>> On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
>> 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 (part
On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas wrote:
> On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
> 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 UPDA
On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
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
> using a very large amount of
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 tracked
19 matches
Mail list logo
