Changes between Initial Version and Version 1 of Ticket #17788, comment 4


Ignore:
Timestamp:
02/29/2012 02:49:30 AM (3 years ago)
Author:
akaariai
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #17788, comment 4

    initial v1  
    1 I also thought about that. I think the better approach would say that every backend has a 1000 parameter limit. That way if you are inserting 2-column rows (m2m tables for example), you could insert 499 items in one query. If they were 20 column items, then you would get to insert 49 and so on.
     1I would implement the above in a way where every backend has 1000 parameter limit. If you are inserting 2-column rows (m2m tables for example), you could insert 499 items in one query. If they were 20 column items, then you would get to insert 49 and so on. 20 objects per call is a little low anyhow.
    22
    3 I think 20 objects per call is a little low anyhow.
     3The above is a bit theoretical. I don't think that change will get accepted for 1.4, and after that it will be backwards incompatible change.
    44
    5 And the above is a bit theoretical anyways, as that change can't be done now.
     5The best approach is to set a 1000 parameter limit for SQLite, no limit for others, and allow override of the default batch size by a kwarg.
    66
    7 I think the best approach is to set a 1000 parameter limit for SQLite, no limit for others, and give a way to define the batch size by a kwarg. I will ask pgsql-general if they have some suggestions about this. I know doing a WHERE id IN large_list isn't efficient, but I don't know if this is true for inserts.
     7I will ask postgresql's performance mailing list if they have some suggestions for preferred batch size. If it is likely the performance will crash if you do too large batch then having a default avoiding this would be good. I know doing a WHERE id IN large_list isn't efficient, but I don't know if this is true for inserts.
    88
    9 I don't think there is any possibility to get the above into 1.4. There is just too little time to fine-tune all the details (transaction handling etc). In addition the above is a new feature. Correct me if I am wrong, I would love to have a more reliable bulk_insert available.
     9I don't think there is any possibility to get the above into 1.4. There is just too little time to fine-tune all the details (transaction handling etc). In addition the above is a new feature.
     10
     11EDIT: rewrote my original post. Me fail english when too little caffeine in the system...
Back to Top