On 27 June 2015 at 15:10, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: > > I have looked into it and found that the main reason for such > > a behaviour is that for those operations it traverses whole > > shared_buffers and it seems to me that we don't need that > > especially for not-so-big tables. We can optimize that path > > by looking into buff mapping table for the pages that exist in > > shared_buffers for the case when table size is less than some > > threshold (say 25%) of shared buffers. > > I don't like this too much because it will fail badly if the caller > is wrong about the maximum possible page number for the table, which > seems not exactly far-fetched. (For instance, remember those kernel bugs > we've seen that cause lseek to lie about the EOF position?) It also > offers no hope of a fix for the other operations that scan the whole > buffer pool, such as DROP TABLESPACE and DROP DATABASE. >
If that is true, then our reliance on lseek elsewhere could also cause data loss, for example by failing to scan data during a seq scan. The consequences of failure of lseek in this case are nowhere near as dire, since by definition the data is being destroyed by the user. So ISTM that we should be able to use this technique. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
