Re: [PERFORM] Optimizer internals

2006-06-23 Thread Bruno Wolff III
On Thu, Jun 15, 2006 at 15:38:32 -0400, John Vincent <[EMAIL PROTECTED]> wrote: > Any suggestions? FYI the original question wasn't meant as a poke at > >comparing PG to MySQL to DB2. I'm not making an yvalue judgements either > >way. I'm just trying to understand how we can use it the best way p

Re: [PERFORM] Optimizer internals

2006-06-21 Thread John Vincent
Any suggestions? FYI the original question wasn't meant as a poke at comparing PG to MySQL to DB2. I'm not making an yvalue judgements either way. I'm just trying to understand how we can use it the best way possible. Actually we just thought about something. With PG, we can create an index that is

Re: [PERFORM] Optimizer internals

2006-06-17 Thread Jim Nasby
On Jun 16, 2006, at 8:43 AM, Jonah H. Harris wrote: Yes, this is certainly the most noticible case. This is one reason I'm behind the freespace patch. Unfortunately, a lot of inexperienced people use VACUUM FULL and don't understand why VACUUM is *generally* better.(to free up block-level frees

Re: [PERFORM] Optimizer internals

2006-06-16 Thread Jonah H. Harris
On 16 Jun 2006 09:21:01 -0400, Greg Stark <[EMAIL PROTECTED]> wrote: Well Oracle has to do almost all that same work, it's just doing it in a separate place called a rollback segment. Well, it's not really the same work. The process by which Oracle manages UNDO is actually pretty simple and ef

Re: [PERFORM] Optimizer internals

2006-06-16 Thread Greg Stark
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > Now, if we're considering UPDATES (the worst case for PostgreSQL's > current MVCC architecture), then this is (IMHO) a true statement. > There aren't many *successful* commercial databases that incur the > additional overhead of creating another vers

Re: [PERFORM] Optimizer internals

2006-06-16 Thread Jonah H. Harris
On 16 Jun 2006 07:23:26 -0400, Greg Stark <[EMAIL PROTECTED]> wrote: The flip side is that Oracle and others like it have to do a lot of extra footwork to do if you query data that hasn't been committed yet. That footwork has performance implications. Not disagreeing here at all, but considerin

Re: [PERFORM] Optimizer internals

2006-06-16 Thread Greg Stark
Mark Lewis <[EMAIL PROTECTED]> writes: > On Thu, 2006-06-15 at 14:05 -0400, John Vincent wrote: > > Now I've been told by our DBA that we should have been able to wholy > > satisfy that query via the indexes. > > DB2 can satisfy the query using only indexes because DB2 doesn't do > MVCC. Well it

Re: [PERFORM] Optimizer internals

2006-06-15 Thread Mischa Sandberg
Mark Lewis wrote: On Thu, 2006-06-15 at 14:05 -0400, John Vincent wrote: Now I've been told by our DBA that we should have been able to wholy satisfy that query via the indexes. DB2 can satisfy the query using only indexes because DB2 doesn't do MVCC. You can get pretty much the same effect

Re: [PERFORM] Optimizer internals

2006-06-15 Thread John Vincent
decibel=# create index test on i ( sum(i) );ERROR:  cannot use aggregate function in index _expression_ decibel=#BTW, there have been a number of proposals to negate the effect of nothaving visibility info in indexes. Unfortunately, none of them have cometo fruition yet, mostly because it's a very

Re: [PERFORM] Optimizer internals

2006-06-15 Thread Jim C. Nasby
On Thu, Jun 15, 2006 at 03:43:09PM -0400, John Vincent wrote: > >Any suggestions? FYI the original question wasn't meant as a poke at > >comparing PG to MySQL to DB2. I'm not making an yvalue judgements either > >way. I'm just trying to understand how we can use it the best way possible. > > > >If

Re: [PERFORM] Optimizer internals

2006-06-15 Thread John Vincent
Any suggestions? FYI the original question wasn't meant as a poke at comparing PG to MySQL to DB2. I'm not making an yvalue judgements either way. I'm just trying to understand how we can use it the best way possible. If anyone from the bizgres team is watching, have they done any work in this area

Re: [PERFORM] Optimizer internals

2006-06-15 Thread Scott Marlowe
On Thu, 2006-06-15 at 14:21, John Vincent wrote: > On 6/15/06, Mark Lewis <[EMAIL PROTECTED]> wrote: > Unfortunately SUM is in the same boat as COUNT; in order for > it to > return a meaningful result it must inspect visibility > information for > all of the

Re: [PERFORM] Optimizer internals

2006-06-15 Thread John Vincent
On 6/15/06, Mark Lewis <[EMAIL PROTECTED]> wrote: Unfortunately SUM is in the same boat as COUNT; in order for it toreturn a meaningful result it must inspect visibility information forall of the rows.-- MarkWe'll this is interesting news to say the least. We went with PostgreSQL for our warehouse

Re: [PERFORM] Optimizer internals

2006-06-15 Thread Mark Lewis
On Thu, 2006-06-15 at 14:46 -0400, John Vincent wrote: > One question that we came up with is how does this affect other > aggregate functions like MAX,MIN,SUM and whatnot? Being that this is > our data warehouse, we use these all the time. As I've said > previously, I didn't know a human could ge

Re: [PERFORM] Optimizer internals

2006-06-15 Thread John Vincent
On 6/15/06, Mark Lewis <[EMAIL PROTECTED]> wrote: DB2 can satisfy the query using only indexes because DB2 doesn't doMVCC.Although MVCC is generally a win in terms of making the database easierto use and applications less brittle, it also means that the database must inspect the visibility informat

Re: [PERFORM] Optimizer internals

2006-06-15 Thread Mark Lewis
On Thu, 2006-06-15 at 14:05 -0400, John Vincent wrote: > Now I've been told by our DBA that we should have been able to wholy > satisfy that query via the indexes. DB2 can satisfy the query using only indexes because DB2 doesn't do MVCC. Although MVCC is generally a win in terms of making the dat

[PERFORM] Optimizer internals

2006-06-15 Thread John Vincent
I'm not a programmer so understanding the optimizer code is WAY beyond my limits.My question, that I haven't seen answered elsewhere, is WHAT things can affect the choice of an index scan over a sequence scan. I understand that sometimes a sequence scan is faster and that you still have to get the