> order of 10 to 100 of these tables. When doing operations on these tables, I > want to avoid having to do a prepare_query every time for performance > reasons.
Did you measure your performance and find that prepare_query is a bottleneck? > Since the tables have exactly the same schema, in theory I should > be able to use the same prepared statement on any one of those tables. Any > ideas on if this is possible? No, it's not possible, because prepared query contains information about the tables used by the query. Pavel On Fri, Oct 29, 2010 at 11:52 AM, john Papier <johnpap...@gmail.com> wrote: > Hi, > > I need to create multiple tables all having the same schema. The > number/names of the tables will by dynamic. There would be somewhere in the > order of 10 to 100 of these tables. When doing operations on these tables, I > want to avoid having to do a prepare_query every time for performance > reasons. Since the tables have exactly the same schema, in theory I should > be able to use the same prepared statement on any one of those tables. Any > ideas on if this is possible? > > The other options I'm looking at are: > 1. dynamically caching prepared queries > 2. use only one table with an extra index. With only 10-100 tables merged > into one, I figure the extra index would take an extra log100 -> ~10 lookups > in the binary search. The thing is, I need to keep a cursor to where in the > table I was last searching, so I can continue the search from where I left > off, which is why using multiple tables was preferable; i.e., i can track > the row_id, and then resume the search there (WHERE row_id > cursor_row_id). > > Any ideas? > > Thanks, > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
