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
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? |