Re: Optimizer internals

From: "John Vincent" <pgsql-performance(at)lusis(dot)org>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: "PGSQL Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Optimizer internals
Date: 2006-06-15 23:23:39
Message-ID: c841561b0606151623p3ed68f8g3e1df4143549a8d4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> 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 not
> having visibility info in indexes. Unfortunately, none of them have come
> to fruition yet, mostly because it's a very difficult problem to solve.
> But it is something that the community would like to see happen.
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>

Yeah we got the same thing when we tried it.

I thought about the whole thing on the way home and the downside is that we
might have to ditch pgsql.

As far as implementing it, it might make sense to translate READ UNCOMMITTED
to that new functionality. If the default isolation level stays the current
level, the people who need it can use it via WITH UR or somesuch.

I know it's not that easy but it's an idea. I'm also thinking that the table
inheritance we're going to be taking advantage of in 8.1 on the new server
might make the sequence scan less of an issue. The only reason the sequence
scan really blows is that we have a single table with 220M rows and growing.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Lewis 2006-06-15 23:25:17 Re: SAN performance mystery
Previous Message Tom Lane 2006-06-15 22:24:44 Re: SAN performance mystery