Re: Feature Request --- was: PostgreSQL Performance Tuning
От | Carlos Moreno |
---|---|
Тема | Re: Feature Request --- was: PostgreSQL Performance Tuning |
Дата | |
Msg-id | 463A7D12.2010302@mochima.com обсуждение исходный текст |
Ответ на | Re: Feature Request --- was: PostgreSQL Performance Tuning (david@lang.hm) |
Ответы |
Re: Feature Request --- was: PostgreSQL Performance Tuning
|
Список | pgsql-performance |
> I don't think it's that hard to get system time to a reasonable level > (if this config tuner needs to run for a min or two to generate > numbers that's acceptable, it's only run once) > > but I don't think that the results are really that critical. Still --- this does not provide a valid argument against my claim. Ok, we don't need precision --- but do we *need* to have less precision?? I mean, you seem to be proposing that we deliberately go out of our way to discard a solution with higher precision and choose the one with lower precision --- just because we do not have a critical requirement for the extra precision. That would be a valid argument if the extra precision came at a considerable cost (well, or at whatever cost, considerable or not). But my point is still that obtaining the time in the right ballpark and obtaining the time with good precision are two things that have, from any conceivable point of view (programming effort, resources consumption when executing it, etc. etc.), the exact same cost --- why not pick the one that gives us the better results? Mostly when you consider that: > I'd argue that we don't even care about 1,000,000 times per second vs > 1,100,000 times per second, what we care about is 1,000,000 times per > second vs 100,000 times per second Part of my claim is that measuring real-time you could get an error like this or even a hundred times this!! Most of the time you wouldn't, and definitely if the user is careful it would not happen --- but it *could* happen!!! (and when I say could, I really mean: trust me, I have actually seen it happen) Why not just use an *extremely simple* solution that is getting information from the kernel reporting the actual CPU time that has been used??? Of course, this goes under the premise that in all platforms there is such a simple solution like there is on Linux (the exact name of the API function still eludes me, but I have used it in the past, and I recall that it was just three or five lines of code). Carlos --
В списке pgsql-performance по дате отправления: