01:27 <stellar-slack> <matschaffer> lab: you might appreciate https://github.com/stellar/stellar_core_commander/pull/58

01:29 <stellar-slack> <lab> interesting. thanks.

01:30 <stellar-slack> <lab> my single node have run for more than10 hours

01:30 <stellar-slack> <lab> 2015-07-31T09:30:09.182 b190f3 [7812] [LoadGen] INFO Tx/s: 1 target (auto), 0.505 actual (1m EWMA). Pending: 9931594 acct, 49931640 tx. ETA: 32944h23m

01:30 <stellar-slack> <lab> 60k+ accounts created and tps is very slow now

01:34 <stellar-slack> <lab> i think postgres server is required for a serious deployment.

01:34 <stellar-slack> <lab> the sqlite file is about 600MB now

01:37 <stellar-slack> <matschaffer> interesting. Wouldn't expect sqlite to be a bottleneck to early, but could be. graydon might also have some thoughts there

01:38 <stellar-slack> <graydon> yeah that's odd, I would expect sqlite to keep up well for a lot longer. hard to say without a version in front of me. what does perf say as far as hotspots?

01:40 <stellar-slack> <lab> any possible cause is debuger

01:40 <stellar-slack> <graydon> which sort of machine is this on, windows or linux?

01:41 <stellar-slack> <lab> i attached debugger in this run for catching crash

01:41 <stellar-slack> <lab> windows, just upgraded to TDM gcc 5.1

01:41 <stellar-slack> <graydon> right. is this an msvc debug build by any chance?

01:41 <stellar-slack> <graydon> hm

01:42 <stellar-slack> <graydon> I really haven't a clue how sqlite performs in that environment. could be a lot of things, I'd really just be speculating at this point.

01:43 <stellar-slack> <graydon> in general though I expect sqlite to perform quite well

01:44 <stellar-slack> <lab> i will keep eyes on it.

03:32 <stellar-slack> <graydon> fwiw when I run the autoload test on my ~2 year old linux ssd workstation under sqlite I get:

03:32 <stellar-slack> <graydon> 2015-07-30T20:17:09.011 test [] [LoadGen] INFO Tx/s: 48 target (auto), 34.6 actual (1m EWMA). Pending: 488 acct, 89 tx. ETA: 0h16m 2

03:32 <stellar-slack> <graydon> after 100k accounts

03:32 <stellar-slack> <graydon> sqlite solidly outperforms postgres on that config / small size db

14:13 <stellar-slack> <fredolafritte> who is supposed to write to the table history_ledgers ?

14:14 <stellar-slack> <fredolafritte> ruby horizon ?

15:54 <stellar-slack> <scott> @fredolafritte: presently, yes. You should be running the ruby horizon server with IMPORT_HISTORY=true in the environment of the process. Alternatively, you can run `rake db:rebuild_history` from the ruby horizon directory to re-import all data from the connected stellar-core process

15:58 <stellar-slack> <fredolafritte> @scott: : thanks a lot

15:59 <stellar-slack> <fredolafritte> go-horizon queries this table but is empty in my local env

16:04 <stellar-slack> <fredolafritte> rake db:rebuild_history: History::BrokenHistoryChainError: Ledger 12159 not found

16:04 <stellar-slack> <fredolafritte> any ideas ?

16:08 <stellar-slack> <fredolafritte> * ./src/stellar-core --newdb* helps

16:21 <stellar-slack> <fredolafritte> With go-horizon, getting an account leads to the following error:

16:21 <stellar-slack> <fredolafritte> pq: column tl.alphanumcurrency does not exist file=src/github.com/stellar/go-horizon/render/problem/main.go line=65

19:57 <stellar-slack> <jed> Anyone here planning on running stellar-core when the new network is live?

19:58 <stellar-slack> <jed> If you are can you msg me