Florian Pflug writes:
> On Aug12, 2010, at 19:48 , Tom Lane wrote:
>> I'm looking through this patch now. It looks mostly good, but I am
>> wondering just exactly what is the rationale for adding comment
>> statements to the data structures, rather than ignoring them as before.
> To be able to i
Tom Lane wrote:
It could be fixed with enough effort, by having the child threads pass
back their numbers through the child-to-parent pipes. I'm not
interested in doing that myself though.
That does seem an improvement with a very limited user base it's
applicable to. Probably the next us
On Aug12, 2010, at 19:48 , Tom Lane wrote:
> Greg Smith writes:
>> Florian Pflug wrote:
>>> Attached is an updated version (v4).
>
>> I've attached a v5. No real code changes from Florian's version, just
>> some wording/style fixes and rework on the documentation.
>
> I'm looking through this
Greg Smith writes:
> I've attached a v5. No real code changes from Florian's version, just
> some wording/style fixes and rework on the documentation.
I've committed this with some editorialization. The main non-cosmetic
change was that I pulled the latency statistics counters out of the
per-C
Greg Smith writes:
> Florian Pflug wrote:
>> Attached is an updated version (v4).
> I've attached a v5.
BTW, I discovered a rather nasty shortcoming of this patch on platforms
without ENABLE_THREAD_SAFETY. It doesn't work, and what's worse, it
*looks* like it's working, because it gives you pla
Greg Smith writes:
> Florian Pflug wrote:
>> Attached is an updated version (v4).
> I've attached a v5. No real code changes from Florian's version, just
> some wording/style fixes and rework on the documentation.
I'm looking through this patch now. It looks mostly good, but I am
wondering ju
Florian Pflug wrote:
Attached is an updated version (v4).
I've attached a v5. No real code changes from Florian's version, just
some wording/style fixes and rework on the documentation. The user side
is now consistent about calling these statement latencies for example,
even though the
On Aug4, 2010, at 13:58 , Florian Pflug wrote:
> On Aug3, 2010, at 21:16 , Greg Smith wrote:
>>> That was a leftover of the trimming and comment skipping logic, which my
>>> patch moves to process_command.
>>
>> I think there's still a trimming error here--line 195 of the new patch is
>> now re
On Aug3, 2010, at 21:16 , Greg Smith wrote:
>> That was a leftover of the trimming and comment skipping logic, which my
>> patch moves to process_command.
>
> I think there's still a trimming error here--line 195 of the new patch is now
> removing the declaration of "i" just before it sets it t
Florian Pflug wrote:
I created the patch to tune the wal_writer for the synchronous_commit=off case
- the idea being that the COMMIT should be virtually instantaneous if the
wal_writer writes old wal buffers out fast enough.
As I was saying, being able to see the COMMIT times for purposes
On Jul29, 2010, at 00:48 , Greg Smith wrote:
> Finally got around to taking a longer look at your patch, sorry about the
> delay here. Patch itself seems to work on simple tests anyway (more on the
> one suspect bit below). You didn't show what the output looks like, so let's
> start with that b
Finally got around to taking a longer look at your patch, sorry about
the delay here. Patch itself seems to work on simple tests anyway (more
on the one suspect bit below). You didn't show what the output looks
like, so let's start with that because it is both kind of neat and not
what I expect
On Jun 14, 2010, at 2:22 , Greg Smith wrote:
> Florian Pflug wrote:
>> To be able to asses the performance characteristics of the different
>> wal-related options, I patched pgbench to show the average latency of each
>> individual statement. The idea is to be able to compare the latency of the
Florian Pflug wrote:
To be able to asses the performance characteristics of the different
wal-related options, I patched pgbench to show the average latency of each
individual statement. The idea is to be able to compare the latency of the
COMMIT with the ones of the other statements.
Tha
Hi
To be able to asses the performance characteristics of the different
wal-related options, I patched pgbench to show the average latency of each
individual statement. The idea is to be able to compare the latency of the
COMMIT with the ones of the other statements.
This patch adds two new fi
15 matches
Mail list logo