| From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
|---|---|
| To: | Bucky Jordan <bjordan(at)lumeta(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brian Herlihy <btherl(at)yahoo(dot)com(dot)au>, Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Collect stats during seqscan (was: Simple join optimized badly?) |
| Date: | 2006-10-11 20:27:58 |
| Message-ID: | 20061011202758.GQ13487@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Oct 11, 2006 at 10:27:26AM -0400, Bucky Jordan wrote:
> Also, I'm guessing this has already come up at some point, but what
> about allowing PG to do some stat collection during queries? If you're
> touching a lot of data (such as an import process) wouldn't it be more
> efficient (and perhaps more accurate) to collect stats then, rather than
> having to re-scan? It would be nice to be able to turn this on/off on a
> per query basis, seeing as it could have pretty negative impacts on OLTP
> performance...
I suspect that could be highly useful in data warehouse environments
where you're more likely to have to sequential scan a table. It would be
interesting to have it so that a sequential scan that will run to
completion also collects stats along the way.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-10-11 20:52:52 | Re: Scrub one large table against another |
| Previous Message | Brendan Curran | 2006-10-11 17:25:02 | Re: Scrub one large table against another (vmstat output) |