Re: PATCH: pgbench - random sampling of transaction written into log
| От | Tomas Vondra |
|---|---|
| Тема | Re: PATCH: pgbench - random sampling of transaction written into log |
| Дата | |
| Msg-id | 2a6d916b65ee9cec421634fdd5957cd0.squirrel@sq.gransy.com обсуждение |
| Ответ на | Re: PATCH: pgbench - random sampling of transaction written into log (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: PATCH: pgbench - random sampling of transaction
written into log
|
| Список | pgsql-hackers |
On 30 Srpen 2012, 23:44, Robert Haas wrote: > On Thu, Aug 30, 2012 at 3:48 PM, Tomas Vondra <tv@fuzzy.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. OK, let's fix the current patches first. We can add more options later. > >> 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. I'll allow a single option - we can enable combinations that make sense later. > > BTW, I think that using any of these options should automatically > enable -l, rather than requiring it to be specified separately. Good idea. Tomas
В списке pgsql-hackers по дате отправления: