On 11/08/2015 07:40 PM, Tim Chou wrote:
Hi Adrian,
Thank you all the time. I also realized that DBT2 has some bugs.
Actually, I have sent an email to DBT2's mailing list. However, no one
responded me.
The latency of a txn is not high in my test. But the number of txns
processed in one minute are
Hi Adrian,
Thank you all the time. I also realized that DBT2 has some bugs.
Actually, I have sent an email to DBT2's mailing list. However, no one
responded me.
The latency of a txn is not high in my test. But the number of txns
processed in one minute are not high.
Thank you.
Best.
Tim
2015-11
On 11/08/2015 04:50 PM, Tim Chou wrote:
Really CCing list this time.
Hi Adrian,
Thank you for your reply.
I use git to clone the repository (git clone
http://git.code.sf.net/p/osdldbt/dbt2 osdldbt-dbt2).
DBT2's website I used is
http://sourceforge.net/p/osdldbt/dbt2/ci/master/tree
I said my p
On Sun, 2015-11-08 at 17:50 -0500, Tom Lane wrote:
> Oliver Elphick writes:
> > I tried to do this:
> > SELECT p.company, p.start, p.yearend, p.idnum,
> >s.pdno, s.pdend,
> >CASE WHEN nth_value(s.pdend,(row_number() OVER w)::INTEGER -1)
> > OVER w IS NULL
> >
Oliver Elphick writes:
> I tried to do this:
> SELECT p.company, p.start, p.yearend, p.idnum,
>s.pdno, s.pdend,
>CASE WHEN nth_value(s.pdend,(row_number() OVER w)::INTEGER -1)
> OVER w IS NULL
> THEN p.start
> ELSE nth_value(s.pdend,(row
I tried to do this:
SELECT p.company, p.start, p.yearend, p.idnum,
s.pdno, s.pdend,
CASE WHEN nth_value(s.pdend,(row_number() OVER w)::INTEGER -1) OVER
w IS NULL
THEN p.start
ELSE nth_value(s.pdend,(row_number() OVER w)::INTEGER -1) + '1
On 11/07/2015 11:27 PM, Tim Chou wrote:
Hi All,
When I test the DBT2 with a large number of connections, I always get
the error:
Error in read.table(file = file, header = header, sep = sep, quote =
quote, :
no lines available in input
Calls: read.csv -> read.table
I have tracked the file a
Hi moran and others;
yesterday i get the pg problem again, and i use perf top Observation
follows:
PerfTop: 11574 irqs/sec kernel: 2.2% exact: 0.0% [4000Hz cycles], (all,
32 CPUs)
81.39% postgres [.] s_lock
5.42% postgres [.] LWLockAcquire
4.59% pos
