Lukas Kahwe Smith <smith@pooteeweet.org> writes:
> Chris Browne wrote:
>
>> Cacheing tends to make lots of operations run more quickly, ergo in
>> "about the same time," for the small, simple queries.
>
> Well but since the attack is based on inserting data, wouldnt this
> likely cause cache invalidation in many cases?
Perhaps to some degree, but it is not at all clear that it will be
material. If they're adding new tuples to a predictable set of
tables, in large quantity, this will tend to lead to a pattern of:
- Allocating a new page (which will throw in a little bit of variance)
- Adding several tuples to that page
The index work will tend to draw a bunch of pages for the relevant
tables into cache, which should tend to stabilize, unless they're
actually throwing so much data at the system that they're really
making the DB larger, at which point I'd expect the "real" data to
start to disappear, washed out by their data.
--
output = ("cbbrowne" "@" "linuxfinances.info")
http://www3.sympatico.ca/cbbrowne/multiplexor.html
"Lumping configuration data, security data, kernel tuning parameters,
etc. into one monstrous fragile binary data structure is really dumb."
- David F. Skoll
