Re: COPY Fillfactor patch
От | Simon Riggs |
---|---|
Тема | Re: COPY Fillfactor patch |
Дата | |
Msg-id | 1113326798.16721.1479.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: COPY Fillfactor patch (Neil Conway <neilc@samurai.com>) |
Список | pgsql-patches |
On Wed, 2005-04-13 at 00:00 +1000, Neil Conway wrote: > Simon Riggs wrote: > > During recent tuning of the TPC-C workload, I produced the following > > patch to force COPY to leave some space in each data block when it loads > > data into heap relations. > > I can't get too excited about incorporating changes designed solely to > improve performance for the workload of a specific database benchmark. Sometimes we tune for specific workloads, sometimes we need to tune to a generic design pattern that effects many users. Unisys wanted to test and tune a workload that would improve things for the most number of users and I would say I support them in that. Database benchmarks exist for two reasons: - generate some great numbers - they offer a generic workload that stresses PostgreSQL in pseudo-real customer situations, but can be easily re-run, discussed, published and dissected for real insight The first reason helps people to accurately size systems and the second reason helps them save them time and money....but without the first people buy the wrong systems and waste money anyway. IMHO if you care about the second, you should also care about the first. Seriously, if you know a workload that better represents the majority of performance critical database applications then I'll be happy to consider tuning for that at another time. (Seriously). > If the change has merit in some plausible "real world" situations, so be > it -- but if not, I don't see the point. Well, I've used PCTFREE many times with Oracle and DB2. Did it do any good? Well, thats much harder, because you don't get as much chance to tune specific issues like that in the real world, but yes, it makes a difference for *some* real workloads. All? No. Best Regards, Simon Riggs
В списке pgsql-patches по дате отправления: