at the end.
Some numbers for ~700 tests.
- Truncation: SQLite - 34s, PG - 76s.
- Transaction: SQLite - 17s, PG - 18s.
2x speed increase for SQLite.
4x speed increase for PG.
Hope that'll help some of you.
Cheers,
Dmytrii
http://ApproachE.com
On 27/02/2012, at 10:57 AM, Dmytrii Nagirni
ul and to
the point.
Cheers,
Dmytrii
http://www.ApproachE.com
On 24/02/2012, at 9:25 PM, Simon Riggs wrote:
> On Fri, Feb 24, 2012 at 12:16 AM, Dmytrii Nagirniak wrote:
>
>> That's totally fine if PG can't beat SQLite on speed in **this particular
>> case**.
>
On 24/02/2012, at 5:15 AM, Simon Riggs wrote:
> Now all you have to do is parallelise the tests and everything can
> work 10 times quicker and it would be much faster than the time SQLite
> produced.
>
> So using PostgreSQL for testing would be both quicker and more
> accurate, if you set the tes
On 24/02/2012, at 2:22 AM, Simon Riggs wrote:
>> Would appreciate some suggestions.
>
> You really need to explain why this matters...
I've just replied to Adrian with more details. I suppose you don't mind to take
a look there so I won't copy-paste it :)
> You mention a "typical Ruby on Rail
On 24/02/2012, at 2:06 AM, Adrian Klaver wrote:
>>
>> Would appreciate some suggestions.
>
> Not enough information to make suggestions.
Jack Christensen pretty nailed it very well. But I'll answer the particulars
here too:
> Why are you switching databases?
Need FTS from PG. No other reason
On 23/02/2012, at 7:35 PM, Marti Raudsepp wrote:
> If you have lots of very simple queries, then usually much of the
> overhead is in query planning. There are a few tricks to dumb down the
> planner to make it faster -- although that may come at the cost of
> slowing down execution.
>
> * If you
On 23/02/2012, at 5:05 PM, Pavel Stehule wrote:
> SQLite should be faster in single user test - it is optimized for this
> purpose. So you cannot to get same speed from PostgreSQL
That's unfortunate to hear.
But hoped with a bit of tuning to get PG close to SQLite by the fact that I can
change t
On 23/02/2012, at 4:38 PM, Jan Kesten wrote:
> Hi Dmytrii,
>
> just as short idea, put "fsync = off" in your postgres.conf. That turns off
> that after a commit data is forcilby written to disk - if the database
> crashes there might be dataloss.
Thanks. So far I tried:
fsync = off
full_pa
ility or anything, just need
fast specs).
Would appreciate some suggestions.
Cheers,
Dmytrii Nagirniak
http://ApproachE.com <http://www.ApproachE.com>
