| From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
|---|---|
| To: | Kevin Brown <kevin(at)sysexperts(dot)com>, Postgres Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Column correlation drifts, index ignored again |
| Date: | 2004-02-24 20:54:15 |
| Message-ID: | 200402241354.15025.pgsql@bluepolka.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tuesday February 24 2004 1:14, Kevin Brown wrote:
>
> One problem I've been running into is the merge join spilling to disk
> because sort_mem isn't big enough. The problem isn't that this is
> happening, it's that I think the planner is underestimating the impact
> that doing this will have on the time the merge join takes. Does the
> planner even account for the possibility that a sort or join will spill
> to disk? Spilling to disk like that will suddenly cause sequential
> reads to perform much more like random reads, unless the sequential
> scans are performed in their entirety between sorts/merges.
How do you know the merge join is spilling to disk? How are you identifying
that? Just assuming from vmstat? iostat?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Brown | 2004-02-24 21:24:19 | Re: Column correlation drifts, index ignored again |
| Previous Message | Kevin Brown | 2004-02-24 20:14:20 | Re: Column correlation drifts, index ignored again |