Claudio Freire wrote
> Well, of course, they're not magic pixie dust.
Of course they aren't. I think they can make a difference in a sequential
input scenario. But I'm not the one who said that they are fit to
solve the problems me and other people are talking about in this thread.
Claudio Freire wrote
> But is your data really random? (or normal?)
> That's the thing...
I still don't understand.
Even if the data was normal, it wouldn't work. You can try and
change the 3rd parameter in normal_rand and get a "narrower"
distribution, but at the same time the query values should be
narrower... so you'll get the same results.
The problem is: if the range you get between min and max is
too big in each page range, you'll end up scanning a lot of heap
pages.
To me, "the thing" is: has anyone made performance tests of these
minmax indexes with an input that is not sequential?
(BTW I'd like to see tests for the sequential input scenario too...)
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Fast-insertion-indexes-why-no-developments-tp5776227p5777055.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
