Serge, > Anyway, I think maybe we should test all the way through x-match. Maybe > not the x-match itself, but at least up to the part where we create the > in-memory zone-ra index just prior to x-match. I may very well be wrong, > but it seems to me that the layout of things on disk might influence how > fast we can do this in memory.
How data is on disk will definitely help how fast you can put the data in memory. Yes, how data is sorted (indexed) in memory affects performance. > Yes of course you are right, but - in the 200b row case we will be > reading/updating/inserting 10x more objects (using some kind of random > object generation or 10 perturbed copies scheme), so the number of pages > read/written from disk should be about the same. If I understood Jacek > correctly, he basically wants to max out the test platform - i.e. use as > many 2kb rows in 3 strips as we have the space to store, or use realistic > row count (which means we have to shrink to 200b per row to fit all-data > on disk). didn't I say that doing the simulations for a whole strip would be more complicated? ;-) Cheers Maria _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
