From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Jeff Davis" <pgsql(at)j-davis(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synchronized Scan benchmark results |
Date: | 2007-04-04 18:52:50 |
Message-ID: | 1175712770.3623.187.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2007-04-04 at 10:23 -0700, Jeff Davis wrote:
> > - a hash join
>
> This is where I got stuck.
>
> * If it's one big ( > NBuffers/2 ) table and one small table, the small
> table will only serve to occupy some shared_buffers (right?
> * If it's two big tables, a join would be a major operation. I don't
> think it would even choose a hash join in that situation, right?
The large table will do a SeqScan though, so should hit your code. Just
look at the EXPLAIN first.
> To summarize, in the next round of testing, I will
> * disable sync_seqscan_offset completely
> * use recycle_buffers=0 and 32
> * I'll still test against 8.2.3 for consistency in case you suggest
> otherwise.
Sounds OK.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schiltknecht | 2007-04-04 18:55:26 | Re: Auto Partitioning |
Previous Message | Tom Lane | 2007-04-04 18:16:57 | Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch |