I intend to play with some optimizer aspects. Just for fun. I'm a
novice in the DBMS development so I can not promise any available
results but if it can be useful even as yet another failed attempt I
will try.
That's what I want to do:
1. Replace not very useful indexCorrelation with indexCluster
Simon Riggs wrote:
> This type of work is 90% analysis, 10% coding. You'll need to do a lot
> of investigation, lots of discussion and listening.
I absolutely agree with you and I am not about to rush into coding
right now. First of all I'm going to dig a lot in the PG sources,
readme's and so on.
Peter Eisentraut wrote:
> If you know of a more effective way to do that beyond the effective_cache_size
> parameter that we have now, let us know.
I don't know the better way and it is not my goal at all. I think about
more accurate cost estimation of nested loops join and subqueries.
Usual case
Say42 wrote:
> select count(*) from conn.conn20060803 c
> where
> exists (select code from belg_mobile tc
...
Correction: replace 'trunk_codes' with 'belg_mobile'.
---(end of broadcast)---
TIP 1: if posting/readin
Tom Lane wrote:
> Optimizing on the basis of only one example is seldom a good idea...
> and I think you are falling into that trap by supposing that there
> is a "usual case".
Perhaps I am wrong but I assume normalization is a usual case, small
master (parent) tables are not very rare also.
Yes,
Peter Eisentraut wrote:
> But you haven't offered any analysis about the cause of this problem, so any
> speculation about normalization, usual cases, caching effects and so on are
> unfounded and premature.
Ok. My previous message was a bit pompous and unfounded. Sorry.
Below I'll try to explain
Tom Lane wrote:
> I'm having a hard time getting excited about improving this query when
> it's so badly coded in the first place. What's an ORDER BY doing in
> an EXISTS subquery? The LIMIT is unnecessary too. And the inner WHERE
> says nothing so much as "I don't know how to design a database
