Re: [sqlite] Trigger slowness even when it's not fired

> fire; the WHEN clause is evaluated within the context of the trigger, even if > the trigger does not fire at all. > > -Ursprüngliche Nachricht- > Von: sqlite-users-boun...@mailinglists.sqlite.org > [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Hami

Re: [sqlite] Trigger slowness even when it's not fired

glists.sqlite.org] Im Auftrag von Hamish > Symington > Gesendet: Montag, 04. Juli 2016 10:27 > An: sqlite-users@mailinglists.sqlite.org > Betreff: [sqlite] Trigger slowness even when it's not fired > > Hello, > > I have a curious situation involving a trigger, which I’m at a lo

Re: [sqlite] Trigger slowness even when it's not fired

Hi there, > > It's known that triggers aren't SQLite most remarkable strength, even if I > never encountered a situation where their relative slowness significantly > exceeds their usefulness. > In your situation I believe your coumpond triggering condition needs > parenthesis. Your

[sqlite] Trigger slowness even when it's not fired

Hello, I have a curious situation involving a trigger, which I’m at a loss to explain. I’m wondering if someone who knows more about the insides of SQLite can tell me more about why it’s happening. I’m running SQLite 3.8.7. The trigger code is at the bottom of this email. It’s a

[sqlite] Index causes slow queries: any thoughts?

>> In the middle of all that, after the line >> CREATE INDEX idx_Appointment_SaleItemUUID ON Appointment >> (Appointment_SaleItemUUID); >> is some slightly odd output - that's just as it appears in the command line >> output in Terminal on my Mac. > What does "PRAGMA integrity_check;" say about

[sqlite] Index causes slow queries: any thoughts?

Hi all, Sorry for the repeat of this post; I?ve not heard back from anyone, and was hoping someone might have some idea. To recap: The tables we have are: Appointment(Appointment_UUID, Appointment_TxnUUID, Appointment_StartDate, and other columns) Txn(Txn_UUID, Txn_Created, Txn_Reference

[sqlite] Index causing very slow queries

Hello, > On 10 Apr 2015, at 15:38, Hamish Symington > wrote: > >>> A follow up to this. If I run ANALYZE on the ?fast? version of the database >>> - ie *after* I?ve recreated the index - performance drops back to the >>> original slow speed. >> >

[sqlite] Index causing very slow queries

the same tests on Windows if it would be helpful. -- Hamish Symington 07815 081282 : info at hamishsymington.com I also set custom cryptic crosswords: www.customcrypticcrosswords.com (@CustomCryptics on Twitter)

[sqlite] Index causing very slow queries

> > This isn't the only thing that's causing a problem, but it might be the > easiest to fix. > > Simon. > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/

[sqlite] Index causing very slow queries

Hi there, A follow up to this. If I run ANALYZE on the ?fast? version of the database - ie *after* I?ve recreated the index - performance drops back to the original slow speed. Hamish > On 10 Apr 2015, at 14:24, Hamish Symington > wrote: > > Hello, > > I have a curiously

[sqlite] Index causing very slow queries

assive performance improvement? If so, why? What am I doing wrong in the first place? Thanks in advance for your assistance, Hamish -- Hamish Symington 07815 081282 : info at hamishsymington.com I also set custom cryptic crosswords: www.customcrypticcrosswords.com (@CustomCryptics on Twitter)

Re: [sqlite] Ordering of fields in a join

Hi - > Adding the warning to the explain plan output should work well. It'd be a good place for it, I'd agree - it'd've saved me a trawl through the documentation and posting to this list! :) Thanks, Hamish ___ sqlite-users mailing list

Re: [sqlite] Ordering of fields in a join

Hello, > In your schema, SaleItem_SaleUUID collates using NOCASE and Picture_UUID > collates using BINARY. I think you mean SaleItem_PictureUUID, not SaleItem_SaleUUID, but yes. > Note that I was mistaken earlier when I said that "X=Y" and "Y=X" should > result in the same answer. If X and Y

Re: [sqlite] Ordering of fields in a join

Hello, > Perhaps try the forthcoming 3.7.15 preview: > http://www.sqlite.org/sqlite3-20121009.zip > See "Please test the latest SQLite enhancements" for details: > http://comments.gmane.org/gmane.comp.db.sqlite.general/77259 Still present in that, as well. I should note (from further

Re: [sqlite] Ordering of fields in a join

Hamish > > > -- > D. Richard Hipp > d...@sqlite.org > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Hamish Symington ham...@lightbluesoftware.com Twitter: @lighterblue Winner of the

Re: [sqlite] Ordering of fields in a join

>> I was under the impression that the order of fields in the ON clause doesn't >> matter. Is this impression incorrect? > > You should be correct, and the latest version of SQLite has some changes in > which look relevant to this issue. Can you check which version of SQLite > you're using

[sqlite] Ordering of fields in a join

Hello, I've made a new database with the latest version of SQLite, and added two tables, created thus: CREATE TABLE SaleItem (SaleItem_ID integer NOT NULL PRIMARY KEY, SaleItem_UUID varchar NOT NULL DEFAULT '', SaleItem_SaleUUID varchar NOT NULL DEFAULT '', SaleItem_PictureUUID varchar NOT NULL