Re: Thousands of tables versus on table?
От
Heikki Linnakangas
Тема
Re: Thousands of tables versus on table?
Дата
Msg-id
4666625F.9010308@enterprisedb.com
Ответ на
Re: Thousands of tables versus on table? (david@lang.hm)
Список
Дерево обсуждения
Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Mark Lewis <mark.lewis@mir3.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Gregory Stark <stark@enterprisedb.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? Gregory Stark <stark@enterprisedb.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Tom Lane <tgl@sss.pgh.pa.us>
Re: Thousands of tables versus on table? "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Re: Thousands of tables versus on table? Andrew Sullivan <ajs@crankycanuck.ca>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Heikki Linnakangas <heikki@enterprisedb.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Andrew Sullivan <ajs@crankycanuck.ca>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? david@lang.hm
Re: Thousands of tables versus on table? Craig James <craig_james@emolecules.com>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
control of benchmarks (was: Thousands of tables) Andrew Sullivan <ajs@crankycanuck.ca>
Re: control of benchmarks (was: Thousands of tables) "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Craig James <craig_james@emolecules.com>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? Craig James <craig_james@emolecules.com>
Re: Thousands of tables versus on table? "Jonah H. Harris" <jonah.harris@gmail.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? Gregory Stark <stark@enterprisedb.com>
Re: Thousands of tables versus on table? "Y Sidhu" <ysidhu@gmail.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
Re: Thousands of tables versus on table? PFC <lists@peufeu.com>
Re: Thousands of tables versus on table? Thomas Andrews <tandrews@soliantconsulting.com>
david@lang.hm wrote: > On Wed, 6 Jun 2007, Steinar H. Gunderson wrote: > >> On Tue, Jun 05, 2007 at 05:59:25PM -0400, Tom Lane wrote: >>> I think the main argument for partitioning is when you are interested in >>> being able to drop whole partitions cheaply. >> >> Wasn't there also talk about adding the ability to mark individual >> partitions >> as read-only, thus bypassing MVCC and allowing queries to be satisfied >> using >> indexes only? >> >> Not that I think I've seen it on the TODO... :-) > > now that's a very interesting idea, especially when combined with > time-based data where the old times will never change. That's been discussed, but it's controversial. IMHO a better way to achieve that is to design the dead-space-map so that it can be used to check which parts of a table are visible to everyone, and skip visibility checks. That doesn't require any user action, and allows updates. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-performance по дате отправления
От: weiping
Дата:
От: weiping
Дата: