On Thu, Apr 20, 2017 at 5:24 PM, Claudio Freire <klaussfre...@gmail.com> wrote: >> What's not clear to me is how sensitive the performance of vacuum is >> to the number of cycles used here. For a large index, the number of >> searches will presumably be quite large, so it does seem worth >> worrying about performance. But if we just always used a binary >> search, would that lose enough performance with small numbers of >> segments that anyone would care? If so, maybe we need to use linear >> search for small numbers of segments and switch to binary search with >> larger numbers of segments. > > I just went and tested.
Thanks! > That's after inlining the compare on both the linear and sequential > code, and it seems it lets the compiler optimize the binary search to > the point where it outperforms the sequential search. > > That's not the case when the compare isn't inlined. > > That seems in line with [1], that show the impact of various > optimizations on both algorithms. It's clearly a close enough race > that optimizations play a huge role. > > Since we're not likely to go and implement SSE2-optimized versions, I > believe I'll leave the binary search only. That's the attached patch > set. That sounds reasonable based on your test results. I guess part of what I was wondering is whether a vacuum on a table large enough to require multiple gigabytes of work_mem isn't likely to be I/O-bound anyway. If so, a few cycles one way or the other other isn't likely to matter much. If not, where exactly are all of those CPU cycles going? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
