On 7 November 2018 at 11:46, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2018-11-07 11:40:22 +1300, Thomas Munro wrote: >> PostgreSQL likes to probe the size of relations with lseek(SEEK_END) a >> lot. For example, a fully prewarmed pgbench -S transaction consists >> of recvfrom(), lseek(SEEK_END), lseek(SEEK_END), sendto(). I think >> lseek() is probably about as cheap as a syscall can be so I doubt it >> really costs us much, but it's still a context switch and it stands >> out when tracing syscalls, especially now that all the lseek(SEEK_SET) >> calls are gone (commit c24dcd0cfd). > > I'd really really like to see some benchmarking before embarking on a > more complex scheme. I aesthetically dislike those lseeks, but ...
I agree. It would be good to see benchmarks on this first. Those could be as simple as just some crude local backend cache that stuff the return value of RelationGetNumberOfBlocks in estimate_rel_size into a hashtable and does not take into account the fact that it might change. Should be okay to do some read-only benchmarking. The partitioning case is probably a less interesting case to improve if we get [1] as we'll no longer ask for the size of any pruned partitions. Queries that don't prune any partitions are less likely to notice the extra overhead of the lseek(SEEK_END) since they've probably got more work to do elsewhere. [1] https://commitfest.postgresql.org/20/1778/ -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
