Re: [PERFORM] EXPLAIN ANALYZE on 8.2
От | Martijn van Oosterhout |
---|---|
Тема | Re: [PERFORM] EXPLAIN ANALYZE on 8.2 |
Дата | |
Msg-id | 20061215123052.GJ958@svana.org обсуждение исходный текст |
Ответ на | Re: [PERFORM] EXPLAIN ANALYZE on 8.2 ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: [PERFORM] EXPLAIN ANALYZE on 8.2
|
Список | pgsql-hackers |
On Fri, Dec 15, 2006 at 12:20:46PM +0000, Simon Riggs wrote: > > I > > wrote a patch that tried statistical sampling, but the figures were too > > far off for people's liking. > > Well, I like your ideas, so if you have any more... > > Maybe sampling every 10 rows will bring things down to an acceptable > level (after the first N). You tried less than 10 didn't you? Yeah, it reduced the number of calls as the count got larger. It broke somewhere, though I don't quite remember why. > Maybe we can count how many real I/Os were required to perform each > particular row, so we can adjust the time per row based upon I/Os. ISTM > that sampling at too low a rate means we can't spot the effects of cache > and I/O which can often be low frequency but high impact. One idea is to sample at fixed interval. Where the I/O cost is high, there'll be a lot of sampling points. The issue being that the final result are not totally accurate anymore. > > I think the best option is setitimer(), but it's not POSIX so > > platform support is going to be patchy. > > Don't understand that. I thought that was to do with alarms and signals. On my system the manpage say setitimer() conforms to: SVr4, 4.4BSD. I'm unsure how many of the supported platforms fall under that catagorisation. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: