issue_comments

That's a good optimization. Still need to deal with the huge flurry of PRAGMA queries though before I can consider this done.

Rather than adding a executemany=True parameter, I'm now thinking a better design might be to have three methods:

• db.execute_write(sql, params=None, block=False)
• db.execute_writescript(sql, block=False)
• db.execute_writemany(sql, params_seq, block=False)

The implementation of cursor.executemany() looks very efficient - it turns into a call to this C function with multiple set to 1: https://github.com/python/cpython/blob/e002bbc6cce637171fb2b1391ffeca8643a13843/Modules/_sqlite/cursor.c#L468-L469

Using executescript=True that call now takes 1.89ms to create all of those tables.

Idea: teach execute_write to accept an optional executescript=True parameter, like this: ```diff diff --git a/datasette/database.py b/datasette/database.py index 468e936..1a424f5 100644 --- a/datasette/database.py +++ b/datasette/database.py @@ -94,10 +94,14 @@ class Database: f"file:{self.path}{qs}", uri=True, check_same_thread=False )

• async def execute_write(self, sql, params=None, block=False):
• async def execute_write(self, sql, params=None, executescript=False, block=False):
• assert not executescript and params, "Cannot use params with executescript=True" def _inner(conn): with conn:
• return conn.execute(sql, params or [])
• if executescript:
• return conn.executescript(sql)
• else:
• return conn.execute(sql, params or [])

   with trace("sql", database=self.name, sql=sql.strip(), params=params):
       results = await self.execute_write_fn(_inner, block=block)
  

  ```

One downside of conn.executescript() is that it won't be picked up by the tracing mechanism - in fact nothing that uses await db.execute_write_fn(fn, block=True) or await db.execute_fn(fn, block=True) gets picked up by tracing.

Also: running all of those CREATE TABLE IF NOT EXISTS in a single call to conn.executescript() rather than as separate queries may speed things up too.

A simpler optimization would be just to turn all of those column and index reads into a single efficient UNION query against each database, then figure out the most efficient pattern to send them all as writes in one go as opposed to calling .execute_write() in a loop.

Now that trace sees write queries (#1568) it's clear that there is a whole lot more DB activity then I had realized:

Maybe it would be worth exploring attaching each DB in turn to the _internal connection in order to perform these queries faster.

I'm a bit worried about leaks though: the internal database isn't meant to be visible, even temporarily attaching another DB to it could cause SQL queries against that DB to be able to access the internal data.

So maybe instead the _internal connection gets to connect to the other DBs? There's a maximum of ten there I think, which is good for most but not all cases. But the cases with the most connected databases will see the worst performance!

Here's why - trace only applies to read, not write SQL operations: https://github.com/simonw/datasette/blob/7c8f8aa209e4ba7bf83976f8495d67c28fbfca24/datasette/database.py#L209-L211

I wonder why the INSERT INTO queries don't show up in that ?trace=1 view?

I was thinking it might even be possible to convert this into a insert into tables select from ... query:

https://github.com/simonw/datasette/blob/c00f29affcafce8314366852ba1a0f5a7dd25690/datasette/utils/internal_db.py#L102-L112

But the SELECT runs against a separate database from the INSERT INTO, so I would have to setup a cross-database connection for this which feels a little too complicated.

I think all of these queries happen in one place - in the populate_schema_tables() function - so optimizing them might be localized to just that area of the code, which would be nice:

https://github.com/simonw/datasette/blob/c00f29affcafce8314366852ba1a0f5a7dd25690/datasette/utils/internal_db.py#L97-L183