Re: increasing collapse_limits?
От | Mark Kirkwood |
---|---|
Тема | Re: increasing collapse_limits? |
Дата | |
Msg-id | 4DBCA4F7.4070803@catalyst.net.nz обсуждение исходный текст |
Ответ на | Re: increasing collapse_limits? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: increasing collapse_limits?
|
Список | pgsql-hackers |
On 01/05/11 11:53, Greg Stark wrote: <blockquote cite="mid:BANLkTikP66KizPDXsvqCtibYLCfXxS7yBw@mail.gmail.com" type="cite"><prewrap="">On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a>wrote: </pre><blockquote type="cite"><pre wrap="">- 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). </pre></blockquote><pre wrap=""> It sounds like you're describing precisely a "star schema" join which isn't an uncommon design pattern at all. </pre></blockquote><font size="-1"><font face="Helvetica"><br /> Nice example here:<br /><br /><a class="moz-txt-link-freetext" href="http://archives.postgresql.org/pgsql-bugs/2011-04/msg00100.php">http://archives.postgresql.org/pgsql-bugs/2011-04/msg00100.php</a><br /><br/> Strictly only a 'star-like' query as the foreign key references go the opposite way from a true star. However itillustrates the planner memory growth well (1.1G on 32-bit 1.7G on 64-bit systems).<br /><br /> A point I didn't mentionis that the memory use is quite dependent on the choice of "word" values for the "AND keyword = 'word'" clause - thetext example had 6 all the same. Setting them all different (even after adjusting the data so the there *was* a numberof matching rows to find) resulted in significantly less memory consumed (I can dig up some examples if it might beinteresting).<br /><br /> Cheers<br /><br /> Mark<br /></font></font>
В списке pgsql-hackers по дате отправления: