Re: Automating Partitions in PostgreSQL - Query on syntax
От | steven king |
---|---|
Тема | Re: Automating Partitions in PostgreSQL - Query on syntax |
Дата | |
Msg-id | 20090421182911.311010@gmx.net обсуждение исходный текст |
Ответ на | Re: Automating Partitions in PostgreSQL - Query on syntax (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Automating Partitions in PostgreSQL - Query on syntax
|
Список | pgsql-hackers |
-------- Original-Nachricht -------- > Datum: Tue, 21 Apr 2009 13:36:19 -0400 > Von: Robert Haas <robertmhaas@gmail.com> > An: steven king <vacuum@quantentunnel.de> > CC: Greg Stark <stark@enterprisedb.com>, pgsql-hackers@postgresql.org, listas@guedesoft.net > Betreff: Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax > > SWITCH <expression> > > CASE <key_value> TABLE <table> [IN <table_space>] > > CASE <key_value> TABLE <table> [IN <table_space>] > > DEFAULT <table> [IN <table_space>] > > > > that is generic > > Rather than SWITCH <expression> CASE <value> ... you probably would > want to reuse the existing PostgreSQL syntax of CASE <expression> WHEN > <value>... I think - at first we've to ask for the problem we have to solve. The syntax it isnt. If we get confused with CASE of CASE THEN ELSE - we can use other keywords .. forinstance SWITCH <expression>ON <value> USE ... that should not the problem. You talking about 1000s of partitions - I cant see that this is the major use-case of table partitioning .. Who wants thousandsof partitions? We simply need a tool to create partitions for common use-cases. Maybe we should provide two or more types of partitioningstrategies. 1. key-range partitioning 2. constraint exclusion partitioning 3.? auto-partitioning (for performance issues only) -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
В списке pgsql-hackers по дате отправления: