From: | Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> |
---|---|
To: | "Lawrence, Ramon" <ramon(dot)lawrence(at)ubc(dot)ca> |
Cc: | "Greg Stark" <stark(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: a few crazy ideas about hash joins |
Date: | 2009-04-03 21:18:40 |
Message-ID: | 82D9D935-8B83-4729-BE67-C7B3F5718AE8@pointblue.com.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3 Apr 2009, at 19:44, Lawrence, Ramon wrote:
>>> I would be especially interested in using a shared memory hash table
>>> that *all* backends can use - if the table is mostly read-only, as
>>> dimension tables often are in data warehouse applications. That
> would
>>> give zero startup cost and significantly reduced memory.
>>
>> I think that's a non-starter due to visibility issues and handling
>> inserts and updates. Even just reusing a hash from one execution in a
>> later execution of the same plan would be tricky since we would have
>> to expire it if the snapshot changes.
>
> If your data set is nearly read-only, materialized views would be a
> better way to go and would require no hash join changes.
I think what he means is that some of the tables in join are
effectively read-only. So materialized views are nono here. Unless you
mean just a partial ones.
I have to say, that frankly I got same problem, and plausibly my
schemas could benefit from changes discussed here.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-03 21:46:05 | Saner interval hash function |
Previous Message | Simon Riggs | 2009-04-03 21:14:51 | Re: GetCurrentVirtualXIDs() |