From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: ALTER SET DISTINCT vs. Oracle-like DBMS_STATS |
Date: | 2009-07-07 02:06:24 |
Message-ID: | 20090707105852.946E.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Euler Taveira de Oliveira <euler(at)timbira(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2009-07-07 03:47:31 | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby |
Previous Message | Greg Stark | 2009-07-06 22:14:13 | Re: Join optimization for inheritance tables |