On Thu, 28 Jan 2016 22:08:02 +0200
R Smith wrote:
> I think you are misunderstanding the Pragma and the idea of automatic
> indices. An automatic Index might be created on a table that doesn't
> have an adequately assigned primary key. It might also be created during
> a query (mostly SELECT
On Thu, 28 Jan 2016 19:18:06 -0500
"Keith Medcalf" wrote:
>
> When you create a table thusly:
>
> create table x (x primary key, y, z);
>
> you are creating a rowid table with columns x, y, an z. You are also saying
> that you want x to be the primary key. Therefore, you will get a table
On Fri, 29 Jan 2016 01:34:01 +0200
R Smith wrote:
>
> I think the dictionary would be faster for this use-case (mostly cause
> it runs in-memory and we do not require all the DB data guarantees for
> the initial sort). However, the fastest way in SQL would be to use a
> temporary table, do
> > You could achieve the same result as follows:
> >
> > create table x (x, y, z);
> > create unique index pk_x_x on x(x);
> >
> > except that now you have given the index on x an explicit name and one
> does not have to be manufactured for you.
> >
>
> I checked these indexes gets created even
On 2016/01/28 11:44 PM, Yannick Duch?ne wrote:
> On Thu, 28 Jan 2016 22:08:02 +0200
> R Smith wrote:
>
> Indeed, I was misunderstanding. Are these indexes visible? Is there
> any relation with the ones I see from sqlitebrowser?
If you mean you are looking at the DB schema and seeing
On Thu, 28 Jan 2016 22:08:02 +0200
R Smith wrote:
> I think you are misunderstanding the Pragma and the idea of automatic
> indices. An automatic Index might be created on a table that doesn't
> have an adequately assigned primary key. It might also be created during
> a query (mostly SELECT
On 2016/01/28 10:08 PM, R Smith wrote:
>
>
> -- Insert Loop start:
> -- This will simply fail if the PK already exists, else start the line
> with 0 count.
> INSERT OR IGNORE INTO element_attribute_values VALUES (:element,
> :attribute, :value, 0);
>
> -- This might be faster since it uses
On 2016/01/28 8:17 PM, Yannick Duch?ne wrote:
> Hi people,
>
> I though automatic index was controlled by the pragma `automatic_index`,
> which seems to do nothing for me, unless I'm doing it the wrong way, while
> `WITHOUT ROWID` on table creations, seems to effectively prevent automatic
>
On Thu, 28 Jan 2016 19:59:02 +0100
Dominique Devienne wrote:
> Not sure to understand what you expect this pragma to do, but inserts
> typically don't involve automatic indexes, which are used only in queries
> (selects).
I though it was responsible for the `sqlite_autoindex_"table_name"_N`
On Thu, Jan 28, 2016 at 7:17 PM, Yannick Duch?ne
wrote:
> I though automatic index was controlled by the pragma `automatic_index`,
> which seems to do nothing for me, unless I'm doing it the wrong way, while
> `WITHOUT ROWID` on table creations, seems to effectively prevent automatic
> indexes,
cr.execute('BEGIN IMMEDIATE')
try:
rowid = cr.execute('select rowid from element_attribute_values where
element=? and attribute=? and value=?', (element, attribute,
value)).fetchone()[0]
cr.execute('update element_attribute_values set count=count+1 where rowid=?',
(rowid,))
except:
> > Not sure to understand what you expect this pragma to do, but inserts
> > typically don't involve automatic indexes, which are used only in
> > queries
> > (selects).
>
> I though it was responsible for the `sqlite_autoindex_"table_name"_N`
> which gets generated and augments the DB size.
Hi people,
I though automatic index was controlled by the pragma `automatic_index`, which
seems to do nothing for me, unless I'm doing it the wrong way, while `WITHOUT
ROWID` on table creations, seems to effectively prevent automatic indexes, the
latter with or without the `PRAGMA
13 matches
Mail list logo
