> Richard Klein wrote:
>> Does SQLite have a mechanism, in addition to the
>> ANALYZE statement, for recording and dumping
>> performance statistics?
>>
>
> What kind of performance statistics are you looking for?
>
> SQLiteSpy (see
>
Richard Klein wrote:
> Does SQLite have a mechanism, in addition to the
> ANALYZE statement, for recording and dumping
> performance statistics?
>
What kind of performance statistics are you looking for?
SQLiteSpy (see
http://www.yunqa.de/delphi/doku.php/products/sqlitespy/index) measures
the
Does SQLite have a mechanism, in addition to the
ANALYZE statement, for recording and dumping
performance statistics?
Thanks,
- Richard Klein
___
sqlite-users mailing list
sqlite-users@sqlite.org
On Wed, Mar 01, 2006 at 09:25:02AM -0500, [EMAIL PROTECTED] wrote:
> I am currently investigating porting my project from postgres to SQLite due
> to anticipated performance issues (we will have to start handling lots more
> data). My initial speed testing of handling the expanded amount data has
On Wed, Mar 01, 2006 at 05:42:57PM +0100, Denis Sbragion wrote:
> Hello Andrew,
>
> On Wed, March 1, 2006 17:31, Andrew Piskorski wrote:
> > Is that in fact true? I am not familiar with how PostgreSQL
> > implements the SERIALIZABLE isolation level, but I assume that
> > PostgreSQL's MVCC would
On Wed, Mar 01, 2006 at 05:23:05PM +0100, Denis Sbragion wrote:
> Insert records as "processing by writer", update them to "ready to be
> processed" with a single atomic update after a burst of inserts, update the
> status of all "ready to be processed" records to the "to be processed by
> reader"
Andrew Piskorski <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 10:53:12AM -0500, [EMAIL PROTECTED] wrote:
> > If you use READ COMMITTED isolation (the default in PostgreSQL)
>
> > If it is a problem,
> > then you need to select SERIALIZABLE isolation in PostgreSQL
> > in which case the
To
> AMsqlite-users@sqlite.org
> cc
>
> Please respond to
Hello Andrew,
On Wed, March 1, 2006 17:31, Andrew Piskorski wrote:
> Is that in fact true? I am not familiar with how PostgreSQL
> implements the SERIALIZABLE isolation level, but I assume that
> PostgreSQL's MVCC would still give some advantage even under
> SERIALIZABLE: It should allow the
> My question is not about extending/improving SQLite but about having an
> extra tool which helps to optimize the SQL written for SQLite. So SQLite
> stays indeed lightweight and fast, but the SQL it is fed with is
> automatically optimized.
Like I said, the optimizer tool is the programmer.
In
On Wed, Mar 01, 2006 at 10:53:12AM -0500, [EMAIL PROTECTED] wrote:
> If you use READ COMMITTED isolation (the default in PostgreSQL)
> If it is a problem,
> then you need to select SERIALIZABLE isolation in PostgreSQL
> in which case the MVCC is not going to give you any advantage
> over SQLite.
My question is not about extending/improving SQLite but about having an
extra tool which helps to optimize the SQL written for SQLite. So SQLite
stays indeed lightweight and fast, but the SQL it is fed with is
automatically optimized.
Ran
On 3/1/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote:
>
> On
Hello DRH,
On Wed, March 1, 2006 16:53, [EMAIL PROTECTED] wrote:
...
> If you use READ COMMITTED isolation (the default in PostgreSQL)
> then your writes are not atomic as seen by the reader. In other
...
> then you need to select SERIALIZABLE isolation in PostgreSQL
> in which case the MVCC is
[EMAIL PROTECTED] said:
> 1. My anticipated bottleneck under postgres is that the DB-writing app.
> must parse incoming bursts of data and store in the DB. The machine
> sending this data is seeing a delay in processing. Debugging has shown
> that the INSERTS (on the order of a few thousand) is
[EMAIL PROTECTED] writes:
> PostgreSQL has a much better query optimizer than SQLite.
> (You can do that when you have a multi-megabyte memory footprint
> budget versus 250KiB for SQLite.) In your particular case,
> I would guess you could get SQLite to run as fast or faster
> than PostgreSQL by
"Denis Sbragion" <[EMAIL PROTECTED]> wrote:
> Furthermore having both a reader
> and a writer at the same time the MVCC "better than row level locking"
> mechanism might provide you better performances than SQLite, but here the
> devil's in the detail.
"D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
On 3/1/06, Ran <[EMAIL PROTECTED]> wrote:
> In light of your answer, I wonder if it is possible to implement such
> optimizer that does the hand-optimizing automatically, but of course BEFORE
> they are actually being used by SQLite.
>
> So the idea is not to make SQLite optimizer better, but to
[EMAIL PROTECTED] wrote:
> wellThe database and the applications accessing the database are all
> located on the same machine, so distribution across multiple machines
> doesn't apply here. The system is designed so that only one application
> handles all the writes to the DB. Another
Hello Jason,
On Wed, March 1, 2006 16:20, [EMAIL PROTECTED] wrote:
...
> 1. My anticipated bottleneck under postgres is that the DB-writing app.
> must parse incoming bursts of data and store in the DB. The machine
> sending this data is seeing a delay in processing. Debugging has shown
> that
In light of your answer, I wonder if it is possible to implement such
optimizer that does the hand-optimizing automatically, but of course BEFORE
they are actually being used by SQLite.
So the idea is not to make SQLite optimizer better, but to create a kind of
SQL optimizer that gets as input
Hello Serge,
On Wed, March 1, 2006 16:11, Serge Semashko wrote:
...
> I'm in no way a database expert, but the tests on the benchmarking page
> seem a bit trivial and looks like they only test database API (data
> fetching throughoutput), but not the engine performance. I would like to
> see some
cc
Please respond to Subject
[EMAIL PROTECTED] Re: [sqlite] performance statistics
te.
Serge Semashko <[EMAIL PROTECTED]> wrote:
>>
> We started with using sqlite3, but the database has grown now to
> something like 1GB and has millions of rows. It does not perform as fast
> as we would like, so we looked for alternatives. We tried to convert
> it to both mysql and postgresql and
[EMAIL PROTECTED] wrote:
I am currently investigating porting my project from postgres to
SQLite due to anticipated performance issues (we will have to start
handling lots more data). My initial speed testing of handling the
expanded amount data has suggested that the postgres performance
[EMAIL PROTECTED] wrote:
>
> I am currently investigating porting my project from postgres to SQLite due
> to anticipated performance issues
>
I do not thing speed should really be the prime consideration
here. PostgreSQL and SQLite solve very different problems.
I think you should choose the
> All -
>
> I am currently investigating porting my project from postgres to SQLite due
> to anticipated performance issues (we will have to start handling lots more
> data). My initial speed testing of handling the expanded amount data has
> suggested that the postgres performance will be
All -
I am currently investigating porting my project from postgres to SQLite due
to anticipated performance issues (we will have to start handling lots more
data). My initial speed testing of handling the expanded amount data has
suggested that the postgres performance will be unacceptable.
27 matches
Mail list logo
