| From: | Matteo Beccati <php(at)beccati(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL 9.0.4 blocking in lseek? |
| Date: | 2011-12-28 14:20:07 |
| Message-ID: | 4EFB2597.1080005@beccati.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
> I'm also trying an EXPLAIN ANALYZE for the SELECT part, but it seems to
> take a while too and is seemingly calling only gettimeofday.
An update on this. Apart from gettimeofday calls, which I filtered out
when logging, I've seen about 80 lseeks recorded every 1h10m (each 1us
apart):
2011-12-28 11:06:25.546661500 lseek(10, 0, SEEK_END) = 27623424
2011-12-28 11:06:25.546662500 lseek(10, 0, SEEK_END) = 27623424
2011-12-28 11:06:25.546663500 lseek(10, 0, SEEK_END) = 27623424
...
2011-12-28 12:16:56.144663500 lseek(10, 0, SEEK_END) = 27623424
...
2011-12-28 13:28:20.436549500 lseek(10, 0, SEEK_END) = 27623424
...
I've then decided to interrupt the EXPLAIN ANALYZE. But I suppose that
the database as it is now will likely allow to further debug what's
happening.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Crate | 2011-12-28 17:22:49 | Re: Subquery flattening causing sequential scan |
| Previous Message | Matteo Beccati | 2011-12-28 09:57:10 | Re: PostgreSQL 9.0.4 blocking in lseek? |