Re: [PERFORM] Some performance numbers, with thoughts

2006-06-28 Thread Ron Mayer
Combining the "insert" statements in a big concatenated string joined by semicolons - rather than sending each individually can drastically speed up your inserts; making them much closer to the speed of copy. For example, instead of sending them separately, it's much faster to send a single strin

Re: [PERFORM] Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)

2006-06-28 Thread Jim C. Nasby
On Wed, Jun 28, 2006 at 10:37:24AM -0400, Tom Lane wrote: > with a plain indexscan. What you need to do is compare the two > functions and figure out what part of the cost models are out of line > with reality. I tend to agree with the upthread comment that the > nonlinear interpolation between m

Re: [PERFORM] Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)

2006-06-28 Thread Tom Lane
Andrew Sagulin <[EMAIL PROTECTED]> writes: > Does PostgreSQL's development team plan to revise the index scan > cost algorithm or issues like mine is too rare for taking into account? The algorithm is certainly open for discussion, but we're not changing it on the basis of just a single report ...

[PERFORM] Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)

2006-06-28 Thread Andrew Sagulin
Wednesday, June 28, 2006, 2:04:17 Simon Riggs, you wrote: > That part is sensible. The min_IO_cost is when the access is sequential, > which by definition has a cost of 1.0. In general - yes. But we talk about the min_IO_cost of the index scan which is barely sequential. Correct me if I'm wrong: