Tom Lane wrote:
>
> Neil Padgett <[EMAIL PROTECTED]> writes:
> > Well. Currently the runs are the typical pg_bench runs.
>
> With what parameters? If you don't initialize the pg_bench database
> with "scale" proportional to the number of clients you
Tom Lane wrote:
>
> Neil Padgett <[EMAIL PROTECTED]> writes:
> > Initial results (top five -- if you would like a complete profile, let
> > me know):
> > Each sample counts as 1 samples.
> > % cumulative self self total
> > time
y via some
neat macros) to all lock acquires / releases. Then, it will be possible
to determine what components are the greatest consumers of locks, and to
determine whether it is a component problem or a systemic problem. (i.e.
some component vs. simply just the lock implementation.)
Neil
--
Marc?
Neil
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister co
s, variables,
etc. rather than just indexing it all as text. This means when you are
looking at a source file with it, you can do neat things like click on a
function call and then see things like the declaration and a x-ref
tree. Very handy.
Neil
--
Neil Padgett
Red Hat Canada Ltd.
int64aligned(log_cnt);
charis_cycled;
charis_called;
} FormData_pg_sequence;
Neil
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
CVS. (Tom?)
Neil
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
