| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Weird index or sort behaviour |
| Date: | 2009-08-18 16:57:29 |
| Message-ID: | 24934.1250614649@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
I wrote:
> Matthew Wakeling <matthew(at)flymine(dot)org> writes:
>> Very clever. Yes, that is what is happening. I'm surprised that the system
>> doesn't buffer the inner side to avoid having to rescan each time, but
>> then I guess you would have problems if the buffer grew larger than
>> memory.
> Well, it does consider adding a Materialize node for that purpose,
> but in this case it evidently thought a sort was cheaper.
Hmmm ... actually, after looking at the code, I notice that we only
consider adding a Materialize node to buffer an inner input that is a
Sort node. The idea was suggested by Greg Stark, if memory serves.
I wonder now if it'd be worthwhile to generalize that to consider
adding a Materialize above *any* inner mergejoin input.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2009-08-18 17:44:21 | Re: Weird index or sort behaviour |
| Previous Message | Tom Lane | 2009-08-18 16:49:37 | Re: Weird index or sort behaviour |