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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Join optimization for inheritance tables
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby