Re: a few crazy ideas about hash joins

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.

In response to

Browse pgsql-hackers by date

  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()