On Fri, Feb 09, 2007 at 05:29:21PM +0900, 原田登志 wrote:
> I found bug in ecpg concerning processing of the multi-byte character-code.
> I reported as bug#2956 before.
Thanks for report and patch.
> Attached is the patch to fix this problem.
This patch is against 8.1, right? I had to apply it manu
Hello
this patch allows using SQL2003 syntax for set returning functions. It is
based on using new type of argmode - PROARGMODE_TABLE.
Proposal: http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php
Sample:
CREATE FUNCTION foof(a int)
RETURNS TABLE(a int, b int) AS
$$ SELECT x, y
The attached adds two new command line switches to pgbench:
-x: Generate extended detail in the latency log, including a timestamp
for each transaction
-X: Do extra cleanup after the run (vacuum on all tables, checkpoint)
before stopping the clock. This gives substantially more consistancy
On Sun, 2007-02-11 at 20:32 -0500, Greg Smith wrote:
> The attached adds two new command line switches to pgbench:
FYI, context diffs are preferred.
> -x: Generate extended detail in the latency log, including a timestamp
> for each transaction
I wonder if it's worth just making this the defau
Neil Conway <[EMAIL PROTECTED]> writes:
> On Sun, 2007-02-11 at 20:32 -0500, Greg Smith wrote:
>> -x: Generate extended detail in the latency log, including a timestamp
>> for each transaction
> I wonder if it's worth just making this the default.
Does this have any impact on the reported resul
On Sun, 2007-02-11 at 23:12 -0500, Tom Lane wrote:
> No, it isn't. This is *not* a candidate for back-porting.
Why is that? It seems to me that the potential downside is essentially
zero. This is a developer-oriented benchmark tool, after all.
-Neil
---(end of broadcas
Neil Conway wrote:
> On Sun, 2007-02-11 at 23:12 -0500, Tom Lane wrote:
>> No, it isn't. This is *not* a candidate for back-porting.
>
> Why is that? It seems to me that the potential downside is essentially
> zero. This is a developer-oriented benchmark tool, after all.
To me, it is a clear lin
On Sun, 11 Feb 2007, Tom Lane wrote:
Does this have any impact on the reported results (by slowing pg_bench
itself)?
I didn't put more code than I had to in the transaction path, to avoid any
slowdown. I didn't convert the timestamp to human readable format or
anything intensive like that t
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> On Sun, 2007-02-11 at 23:12 -0500, Tom Lane wrote:
>>> No, it isn't. This is *not* a candidate for back-porting.
>>
>> Why is that? It seems to me that the potential downside is essentially
>> zero. This is a developer-oriented
Hi,
On 2/12/07, Greg Smith <[EMAIL PROTECTED]> wrote:
The attached adds two new command line switches to pgbench:
-x: Generate extended detail in the latency log, including a timestamp
for each transaction
From your patch I see that it augments the -l flag. IMHO it does not make
sense to
10 matches
Mail list logo
