Hi Tom,
We have managed to improve significantly on the speed of this query.
The way that we did this was through clustering the table based on the
domain index which significantly reduced the page reads that were
required in order to perform the query.
Also to find this we turned on log_st
Bryce Ewing writes:
> So it seems to me that once the index is in memory everything is fine
> with the world, but the loading of the index into memory is horrendous.
So it would seem. What's the disk hardware on this machine?
It's possible that part of the problem is table bloat, leading to th
The nested loops (which are due to the joins) don't seem to be part of
the problem at all. The main time that is taken (actual time that is)
is in this part:
Index Scan using event_20090526_domain_idx on event_20090526 e
(cost=0.00..10694.13 rows=3606 width=1276) (actual
time=50.233..143
Scott Marlowe writes:
> Without looking at the explain just yet, it seems to me that you are
> constraining the order of joins to insist that the left joins be done
> first, then the regular joins second, because of your mix of explicit
> and implicit join syntax. The query planner is constrained
On Tue, Jun 16, 2009 at 9:30 PM, Bryce Ewing wrote:
> Hi,
>
> I have been trying to fix a performance issue that we have which I have
> tracked down to index scans being done on a particular table (or set of
> tables):
>
> The following query:
> explain analyze select *
> FROM inbound.event_2009052
Hi,
I have been trying to fix a performance issue that we have which I have
tracked down to index scans being done on a particular table (or set of
tables):
The following query:
explain analyze select *
FROM inbound.event_20090526 e
LEFT OUTER JOIN inbound.internal_host i ON (e.mta_host_id =
