| From: | NikhilS <nikkhils(at)gmail(dot)com> |
|---|---|
| To: | "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, "Shane Ambler" <pgsql(at)sheeky(dot)biz>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, "Jim Nasby" <decibel(at)decibel(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
| Subject: | Re: Auto creation of Partitions |
| Date: | 2007-03-10 05:13:12 |
| Message-ID: | d3c4af540703092113o3acbe35bo1809765869b52983@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Hi,
> > Given that Simon wants to do away with having the master table APPENDed
> in
> > the planning phase, this would be better.
> >
>
> ISTM you're trading appending the master table for appending the DUMP
> partition, which afaict would give you no gain.
If there are entries in the master table, I think it would get appended for
all queries regardless of whether we need to examine its contents or not.
Segregating dump data into a partition will avoid that.
I have seen examples in some other databases wherein a partition specifies a
range of "someval - MAXINT" for instance, to catch such cases.
That again means that the onus is on the partition creator most of the
times..
Regards,
Nikhils
> --
> Robert Treat
> Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
>
--
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-10 05:32:19 | Re: msvc failure in largeobject regression test |
| Previous Message | NikhilS | 2007-03-10 04:58:55 | Re: Auto creation of Partitions |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-03-10 07:59:55 | Re: scan_recycle_buffers |
| Previous Message | NikhilS | 2007-03-10 04:58:55 | Re: Auto creation of Partitions |