On Sat, Aug 14, 2010 at 9:30 AM, Tom Hughes <t...@compton.nu> wrote: > On 14/08/10 00:19, Grant Slater wrote: > >> On 14 August 2010 00:10, Brett Henderson<br...@bretth.com> wrote: >> >>> >>> Is anybody aware of anything that happened on that day *other* than the >>> database upgrade? Any new imports, etc. >>> >>> >> The database was fully re-imported (planned and triple backed up) and >> the transaction IDs were reset due to this. >> zere was able to set the transaction id used by osmosis diff export >> because I believe you were not around or weren't available at the >> time. >> >> Also: Postgresql 8.3 -> 8.4. RAID10 on 10 disk to RAID 10 on 16 disks. >> RAID stripe size changed from 256KB to 64KB. >> > > There's not really any great mystery here, we know it was the upgrade to > postgres 8.4 (or just as likely the reimport of the db) that triggered it. >
Okay. I didn't realise that a database upgrade had occurred, I thought it was only disk/RAID changes. > > We just need to get to the bottom of what is making some of the queries run > slowly, but it's not a very easy thing to do. > Is it only Osmosis queries that are running slowly? > My assumption was that it was choosing a bad execution plan as the way our > schema works tends to confuse Postgres's statistics, but the plan I looked > at didn't show any sign of that. > > Equally it doesn't seem to be a lock contention issue. > Is there anything I can add that might make it easier to investigate such as additional query options, log query timings, etc? I'm not sure what to try at this point. About the only thing I can think to do is to set up a local database and try to replicate the problem. I've been meaning to do that but it's not a quick task and I haven't had much time to spend on it. Brett
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
