Обсуждение: cost_hashjoin
cost_hashjoin() has some treatment of what occurs when numbatches > 1 but that additional cost is not proportional to numbatches. The associated comment talks about "an extra time", making it sound like we think numbatches would only ever be 2 (or 1). Can someone explain the current code, or is there an oversight there? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
On Mon, Aug 30, 2010 at 10:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > cost_hashjoin() has some treatment of what occurs when numbatches > 1 > but that additional cost is not proportional to numbatches. Because that's not how our hash batching works. We generate two temp files for each batch, one for the outer and one for the inner. So if we're batching then every tuple of both the inner and outer tables (except for ones in the first batch) need to be written once and read once regardless of the number of batches. I do think the hash join implementation is a good demonstration of why C programming is faster at a micro-optimization level but slower at a macro level. Users of higher level languages would be much more likely to use any of the many fancier hashing data structures developed in the last few decades. in particular I think Cuckoo hashing would be interesting for us. -- greg
On Mon, 2010-08-30 at 13:34 +0100, Greg Stark wrote: > On Mon, Aug 30, 2010 at 10:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > cost_hashjoin() has some treatment of what occurs when numbatches > 1 > > but that additional cost is not proportional to numbatches. > > Because that's not how our hash batching works. We generate two temp > files for each batch, one for the outer and one for the inner. So if > we're batching then every tuple of both the inner and outer tables > (except for ones in the first batch) need to be written once and read > once regardless of the number of batches. Thanks for explaining. For some reason I thought we rewound the outer at the start of each batch, which is better for avoiding cache spoiling. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services