From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: pgbench - random sampling of transaction written into log |
Date: | 2012-08-30 21:44:05 |
Message-ID: | CA+TgmoaU+7R8jSkiG_g4UBykUx8vyPec_NC7TqZuop=jp1V7uQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 30, 2012 at 3:48 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> That sounds like a pretty trivial patch. I've been thinking about yet
> another option - histograms (regular or with exponential bins).
I thought about that, too, but I think high-outliers is a lot more
useful. At least for the kinds of things I worry about.
> What I'm not sure about is which of these options should be allowed at the
> same time - to me, combinations like 'sampling + aggregation' don't make
> much sense. Maybe except 'latency-only-if-more-than + aggregation'.
Maybe, but perhaps not even. I don't have a problem with saying that
the user is allowed to pick at most one method of reducing the output
volume. I think we could say: either sample, or take high outliers,
or aggregate. If we want to make some of those work in combination,
fine, but I don't think it's absolutely required. What WILL be
required is a clear error message telling you what you did wrong if
you use an unsupported combination.
BTW, I think that using any of these options should automatically
enable -l, rather than requiring it to be specified separately.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-08-30 21:45:24 | Re: [HACKERS] pg_dump and thousands of schemas |
Previous Message | Bruce Momjian | 2012-08-30 21:43:44 | Re: Pg default's verbosity? |