3 ms·
> The upside is Postgres doesn't have to worry about page splits, so things like bulk inserts can be much more efficient. Not in the heap, but if you have any
by sgarland 2y ago
> The upside is Postgres doesn't have to worry about page splits, so things like bulk inserts can be much more efficient.
Not in the heap, but if you have any index on the table (I know, don’t do that for bulk loads, but many don’t / it isn’t feasible sometimes) then you’re still dealing with a B+tree (probably).
Also, MySQL still gets the nod for pure bulk load speed via MySQLShell’s Parallel Import Utility [0]. You can of course replicate this in Postgres by manually splitting the input file and running multiple \COPY commands, but having a tool do it all in one is lovely.
[0]: https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-parallel-table.html https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-uti...
- tomnipotent 2y ago> then you’re still dealing with a B+tree Absolutely, though they're generally orders of magnitude smaller than the table file unless you're INCLUDE'ing lots of columns. There's pg_bulkload which supports parallel writers as well as deferred index updates until the loading process is complete. Not sure how it compares to what MySQL offers out of the box, but I definitely agree that the MySQL tooling ecosystem in general has a leg up.