On Mon, Apr 20, 2015 at 09:56:20PM +0100, Simon Riggs wrote: > On 20 April 2015 at 20:28, Jeff Janes <jeff.ja...@gmail.com> wrote: > > > But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job, > while the user waits, which is fundamentally VACUUM's duty to do in the > background? > > > Agreed. I don't see a % as giving us anything at all. > > The idea is that we want to turn an O(N) problem for one query into an O(1) > task. > > > The use case I see for this is when there is a mixed workload. There is > one select which reads the entire table, and hundreds of thousands of > selects/updates/insert that don't, and of course vacuum comes along every > now and then and does it thing. Why should the one massive SELECT have > horrible performance just because it was run right before autovacuum would > have kicked in instead of right after if finished? > > > +1
You can +1 all you want, but if you ignore the specific workloads I mentioned, you are not going to get much traction. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
