Re: ALTER SET DISTINCT vs. Oracle-like DBMS_STATS
От | Itagaki Takahiro |
---|---|
Тема | Re: ALTER SET DISTINCT vs. Oracle-like DBMS_STATS |
Дата | |
Msg-id | 20090707105852.946E.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: ALTER SET DISTINCT vs. Oracle-like DBMS_STATS (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
Euler Taveira de Oliveira <euler@timbira.com> wrote: > >> INSERT INTO dbms_stats.columns(starelid, ataattnum, stadistinct) > >> VALUES ('tablename'::regclass, 3, 100); > > > > Why wouldn't you implement this through reloptions? > > > Because it is column-based and not table-based? In this case, we need to store > and array value like {attnum, stadistinct}. If it is not ugly in your POV, +1 > for this approach. Yes, column-based storage is needed. However, when we drop tables, dangling stat settings might remain. I want core-support for the module, for example, "TRIGGER ON DROP TABLE" or some drop-relation-hooks. There might be another approach that we add pg_attribute.attoptions for generic column-based options, like pg_class.reloptions. Which approach is better, or something else? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: