Edmund Mergl <E.Mergl@bawue.de> writes:
> Some more numbers:
> database #rows inserts create make_sqs make_nqs
> index selects updates
> ----------------------------------------------------------------------------
> pgsql 10.000 00:24 00:09 00:16 00:25
> pgsql 100.000 04:01 01:29 01:06 49:45
> pgsql 1.000.000 39:24 20:49 23:42 ???
> whereas the increase of elapsed time is somewhat proportional
> to the number of rows, for the update-case it is rather
> exponential.
Those are attention-getting numbers, all right. I think that the two
equal-key problems I found last night might partially explain them;
I suspect there are more that I have not found, too. I will look into
it some more.
Could you try the same queries with no indexes in place, and see what
the time scaling is like then? That would confirm or deny the theory
that it's an index-update problem.
Question for the hackers list: are we prepared to install purely
performance-related bug fixes at this late stage of the 6.5 beta cycle?
Bad as the above numbers are, I hesitate to twiddle the btree code and
risk breaking things with only a week of testing time to go...
regards, tom lane
