Re: increasing collapse_limits?

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: increasing collapse_limits?
Date: 2011-05-01 00:10:31
Message-ID: 4DBCA4F7.4070803@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/05/11 11:53, Greg Stark wrote:
> On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> - it would require a query in which
>> every relation is linked to every other relation by a join clause.
>> But that *can* happen (remember that clauses generated by transitive
>> equality do count).
> It sounds like you're describing precisely a "star schema" join which
> isn't an uncommon design pattern at all.
>

Nice example here:

http://archives.postgresql.org/pgsql-bugs/2011-04/msg00100.php

Strictly only a 'star-like' query as the foreign key references go the
opposite way from a true star. However it illustrates the planner memory
growth well (1.1G on 32-bit 1.7G on 64-bit systems).

A point I didn't mention is that the memory use is quite dependent on
the choice of "word" values for the "AND keyword = 'word'" clause - the
text example had 6 all the same. Setting them all different (even after
adjusting the data so the there *was* a number of matching rows to find)
resulted in significantly less memory consumed (I can dig up some
examples if it might be interesting).

Cheers

Mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2011-05-01 00:37:10 Re: Proposed patch: Smooth replication during VACUUM FULL
Previous Message Greg Stark 2011-04-30 23:53:04 Re: increasing collapse_limits?