Re: Why does this query write to the disk?

Under what conditions does EXPLAIN ANALYZE report spilling work_mem to
disk? When does it not report work_mem or other overflow to disk?
I know that a planned disk-sort shows up. I have also seen it report a
hash-agg on disk, but this was a while ago and rather difficult to reproduce
and I'm somewhat confident I have seen it spill to temp disk without
reporting it in EXPLAIN ANALYZE, but I could be wrong.

On Thu, Sep 18, 2008 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> > "Nikolas Everett" <nik9000(at)gmail(dot)com> wrote:
> >> I'm a bit confused as to why this query writes to the disk:
>
> > It's probably writing hint bits to improve performance of subsequent
> > access to the table. The issue is discussed here:
> > http://wiki.postgresql.org/wiki/Hint_Bits
>
> Hint-bit updates wouldn't be WAL-logged. If the table has been around a
> long time, it might be freezing old tuples, which *would* be WAL-logged
> (since 8.2 or so) --- but that would be a one-time, non-repeatable
> behavior. How sure are you that there was WAL output?
>
> What I was thinking was more likely was that the hash table for the hash
> join was spilling out to temp files. That wouldn't be WAL-logged
> either, but depending on your tablespace setup it might result in I/O on
> some other disk than the table proper.
>
> regards, tom lane
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>