> This is pretty similar to the proposal Atri and I just recently made. > I am 100% in agreement that something must be done here...SELECT has > none of the i/o mitigation features that vacuum has. Is your idea > better? probably (although you have to give a small penalty for a user > facing tunable) but we need testing against real world workloads, or > at least a much better synthetic one than pgbench, which per recent > discussions is probably the top objective of the project (a > performance farm, etc.). >
I have been working on some tests for improving the performance in case of bulk INSERTs for our patch. So far, I think it has some relation to the visibility map optimization, which our patch seems to be affecting. Some more testing is in place, which has been delayed due to me being wound up in other projects. Now that they are complete, I will resume testing next week or so. Regards, Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
