On May 6, 2011, at 4:15 PM, Andrew Sullivan wrote:
> Yeah, in that case the HOT suggestions are very important. I strongly
> recomment you experiment in a test system with real data and
> pathological cases in particular, in order to see what happens when
> the outlier cases inevitably, Murphy wi
On Fri, May 06, 2011 at 03:43:02PM -0600, Scott Ribe wrote:
> In this case, it depends on the result of a pretty complex join that
> involves some gnarly time calculations, and finding the unmatched
> rows from one side of an outer join.
Yeah, in that case the HOT suggestions are very important.
On May 6, 2011, at 1:39 PM, Tomas Vondra wrote:
> Anyway I'd recommend to start with the eager approach, it's much easier
> to implement. You can implement the lazy approach later, if you find out
> it's needed.
With the eager approach, I think I'm too likely to get write conflicts. Thanks
for t
On Fri, May 06, 2011 at 12:45:23PM -0600, Scott Ribe wrote:
> I need to optimize queries that deal with some aggregates regarding
resource availability. My specific problem is, I think, very closely
analogous to select count(*)... where...
If the WHERE clause is fairly selective and indexed,
Dne 6.5.2011 20:45, Scott Ribe napsal(a):
> I need to optimize queries that deal with some aggregates regarding
> resource availability. My specific problem is, I think, very closely
> analogous to select count(*)... where...
>
> I know roughly how to do it, aggregated stats table, triggers
> appe
I need to optimize queries that deal with some aggregates regarding resource
availability. My specific problem is, I think, very closely analogous to select
count(*)... where...
I know roughly how to do it, aggregated stats table, triggers appending to it,
occasional updates to coalesce entries
