Skip site navigation (1) Skip section navigation (2)

Re: review: pgbench - aggregation of info written into log

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: pgbench - aggregation of info written into log
Date: 2013-01-17 09:36:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 17, 2013 at 2:35 AM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>>>> This might be way more than we want to do, but there is an article
>>>> that describes some techniques for doing what seems to be missing
>>>> (AIUI):
>>>> <>
>>> Even this would be doable, I'm afraid it may not fit in 9.3 if we
>>> think about the current status of CF. So our choice would be:
>>> 1) Postpone the patch to 9.4
>>> 2) Commit the patch in 9.3 without Windows support
>>> I personally am ok with #2. We traditionally avoid particular paltform
>>> specific features on PostgreSQL.  However I think the policiy could be
>>> losen for contrib staffs. Also pgbench is just a client program. We
>>> could always use pgbench on UNIX/Linux if we truely need the feature.
>>> What do you think?
>> Fair enough, I was just trying to point out alternatives. We have
>> committed platform-specific features before now. I hope it doesn't
>> just get left like this, though.

We have committed platform-specific features before, but generally
only when it's not *possible* to do them for all platforms. For
example the posix_fadvise stuff isn't available on Windows at all, so
there isn't much we can do there.

> Yeah, I hope someone pick this up and propose as a TODO item. In the
> mean time, I'm going to commit the patch without Windows support
> unless there's objection.

Perhaps we should actually hold off until someone committs to actually
getting it fixed in the next version? If we do have that, then we can
commit it as a partial feature, but if we just "hope someone picks it
up", that's leaving it very loose..

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2013-01-17 09:55:07
Subject: Re: Removing PD_ALL_VISIBLE
Previous:From: Abhijit Menon-SenDate: 2013-01-17 09:27:13
Subject: Re: Removing PD_ALL_VISIBLE

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group