Re: [sqlite] Full covering index without table

On Thu, Mar 7, 2013 at 11:50 AM, Richard Hipp wrote: > When a row is larger than a single page, the content spills into multiple > pages where the pages are strung together as a linked list. You have to > read each page in order to follow the linked list. That makes sense.

Re: [sqlite] Full covering index without table

On Thu, Mar 7, 2013 at 3:50 AM, Dominique Devienne wrote: > On Tue, Mar 5, 2013 at 4:05 PM, Richard Hipp wrote: > > Both implementations allow for reading just the prefix of the content > blob > > in order to access earlier fields of a table, leaving the

Re: [sqlite] Full covering index without table

On Thu, Mar 7, 2013 at 9:50 AM, Dominique Devienne wrote: > On Tue, Mar 5, 2013 at 4:05 PM, Richard Hipp wrote: > > Both implementations allow for reading just the prefix of the content blob > > in order to access earlier fields of a table, leaving the tail

Re: [sqlite] Full covering index without table

On Tue, Mar 5, 2013 at 4:05 PM, Richard Hipp wrote: > Both implementations allow for reading just the prefix of the content blob > in order to access earlier fields of a table, leaving the tail of the blob > unread on disk. This information sparked a bit of a debate among my

Re: [sqlite] Full covering index without table

On Tue, Mar 5, 2013 at 12:11 PM, Tim Streater wrote: > On 05 Mar 2013 at 15:05, Richard Hipp wrote: > > > Both implementations allow for reading just the prefix of the content > blob > > in order to access earlier fields of a table, leaving the tail of

Re: [sqlite] Full covering index without table

On 05 Mar 2013 at 15:05, Richard Hipp wrote: > Both implementations allow for reading just the prefix of the content blob > in order to access earlier fields of a table, leaving the tail of the blob > unread on disk. So in all cases, it pays to put your frequently accessed >

Re: [sqlite] Full covering index without table

On 5 Mar 2013, at 3:05pm, Richard Hipp wrote: > I think you have misunderstood too. Both SQLite3 and SQLite4 are > row-oriented databases. The storage engines are very different, but they > still store each row as a single big blob Okay, yep. I did misunderstand what was

Re: [sqlite] Full covering index without table

On Tue, Mar 5, 2013 at 9:45 AM, Simon Slavin wrote: > > On 5 Mar 2013, at 2:37pm, Richard Hipp wrote: > > > On Tue, Mar 5, 2013 at 9:26 AM, Simon Slavin > wrote: > > > >> I've seen programs written by people who always do 'SELECT *"

Re: [sqlite] Full covering index without table

On 5 Mar 2013, at 2:37pm, Richard Hipp wrote: > On Tue, Mar 5, 2013 at 9:26 AM, Simon Slavin wrote: > >> I've seen programs written by people who always do 'SELECT *" even when >> they want just a couple of fields. That's going to be a lot more

Re: [sqlite] Full covering index without table

On Tue, Mar 5, 2013 at 9:26 AM, Simon Slavin wrote: > I've seen programs written by people who always do 'SELECT *" even when > they want just a couple of fields. That's going to be a lot more expensive > under SQLite4. Maybe it'll teach them to be better programmers. >

Re: [sqlite] Full covering index without table

On 5 Mar 2013, at 11:54am, Eleytherios Stamatogiannakis wrote: > I'm not so sure how fast SQLite4 will be with respect to full scans. IMHO row > stores have an advantage when scanning over multiple columns. I was thinking about that. I've seen programs written by people

Re: [sqlite] Full covering index without table

I'm not so sure how fast SQLite4 will be with respect to full scans. IMHO row stores have an advantage when scanning over multiple columns. Concerning dropping the index and recreating it on the other side. Its doable but very bad from a performance point of view. If you know how the other

Re: [sqlite] Full covering index without table

SQLite4 gets this right... Of course, it's not been released. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Full covering index without table

On Tue, Mar 5, 2013 at 1:59 AM, Carlos Milon Silva wrote: > Also, You could not rebuild the index from the index, if necessary. I'm not sure what your point is Carlos. The table is the index, so there's no index to drop or rebuild. What Eleytherios is referring to, is known

Re: [sqlite] Full covering index without table

Also, You could not rebuild the index from the index, if necessary. Carlos. Em 04/03/2013 12:44, Simon Slavin escreveu: On 4 Mar 2013, at 4:13pm, Eleytherios Stamatogiannakis wrote: Is there a way in SQLite to have a full covering index on a table without also storing the

Re: [sqlite] Full covering index without table

On 04/03/13 18:44, Simon Slavin wrote: On 4 Mar 2013, at 4:13pm, Eleytherios Stamatogiannakis wrote: Is there a way in SQLite to have a full covering index on a table without also storing the duplicate table? Can we ask why you care about this ? Do you have a huge table

Re: [sqlite] Full covering index without table

On 4 Mar 2013, at 4:13pm, Eleytherios Stamatogiannakis wrote: > Is there a way in SQLite to have a full covering index on a table without > also storing the duplicate table? Can we ask why you care about this ? Do you have a huge table which is taking a huge amount of

[sqlite] Full covering index without table

Hi, I have a question: Is there a way in SQLite to have a full covering index on a table without also storing the duplicate table? So if a have a table: create table t(a,b,c); and an index covering all its columns: create index idx_t on t(a,b,c); SQLite will store everything twice. First