Re: Optimizer internals
От
John Vincent
Тема
Re: Optimizer internals
Дата
Msg-id
c841561b0606151623p3ed68f8g3e1df4143549a8d4@mail.gmail.com
Ответ на
Re: Optimizer internals (Jim C. Nasby)
Список
Дерево обсуждения
Optimizer internals "John Vincent" <pgsql-performance@lusis.org>
Re: Optimizer internals Mark Lewis <mark.lewis@mir3.com>
Re: Optimizer internals Mischa Sandberg <mischa@ca.sophos.com>
Re: Optimizer internals Greg Stark <gsstark@mit.edu>
Re: Optimizer internals "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Optimizer internals Greg Stark <gsstark@mit.edu>
Re: Optimizer internals "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Optimizer internals Jim Nasby <decibel@decibel.org>
Re: Optimizer internals "John Vincent" <pgsql-performance@lusis.org>
Re: Optimizer internals Mark Lewis <mark.lewis@mir3.com>
Re: Optimizer internals "John Vincent" <pgsql-performance@lusis.org>
Re: Optimizer internals Scott Marlowe <smarlowe@g2switchworks.com>
Re: Optimizer internals "John Vincent" <lusis.org@gmail.com>
Re: Optimizer internals Bruno Wolff III <bruno@wolff.to>
Re: Optimizer internals "John Vincent" <pgsql-performance@lusis.org>
Re: Optimizer internals "Jim C. Nasby" <jnasby@pervasive.com>
Re: Optimizer internals "John Vincent" <pgsql-performance@lusis.org>
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@pervasive.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.
В списке pgsql-performance по дате отправления
