| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PERFORM] Slow query: bitmap scan troubles |
| Date: | 2013-01-14 16:45:01 |
| Message-ID: | CA+TgmoYQ6Nq-tpHiDPCUH3CkH2N9D67=oDKJtLxuRRC=dRteSQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Thu, Jan 10, 2013 at 8:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Comments?
I'm not sure I have anything intelligent to add to this conversation -
does that make me the wisest of all the Greeks? - but I do think it
worth mentioning that I have heard occasional reports within EDB of
the query planner refusing to use extremely large indexes no matter
how large a hammer was applied. I have never been able to obtain
enough details to understand the parameters of the problem, let alone
reproduce it, but I thought it might be worth mentioning anyway in
case it's both real and related to the case at hand. Basically I
guess that boils down to: it would be good to consider whether the
costing model is correct for an index of, say, 1TB.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2013-01-14 16:45:38 | Re: Get current query in a trigger function |
| Previous Message | Robert Haas | 2013-01-14 16:32:49 | Re: json api WIP patch |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-01-14 17:23:17 | Re: [PERFORM] Slow query: bitmap scan troubles |
| Previous Message | Boszormenyi Zoltan | 2013-01-14 14:28:48 | Re: Two Necessary Kernel Tweaks for Linux Systems |