| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> | 
|---|---|
| To: | April Lorenzen <outboundindex(at)gmail(dot)com> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: error-free disabling of individual child partition tables | 
| Date: | 2006-05-22 19:22:00 | 
| Message-ID: | 20060522192200.GG64371@pervasive.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, May 22, 2006 at 02:25:09PM -0400, April Lorenzen wrote:
> It comes up repeatedly that I need to load fresh data into a new
> table, build indexes and vacuum - then drop the old table and
> substitute the new.
 
Why are you vacuuming a brand new table? Just run analyze.
> Postgresql partioning makes this all almost possible: the master
> automatically SELECTs from all the child tables - so it automatically
> recoginize the new ones, and no loss when the old ones are dropped.
 
How is that any better than:
BEGIN;
-- Don't do the drop right now, because it might take awhile
ALTER TABLE tablename RENAME TO delete_tablename;
ALTER TABLE temporary_tablename RENAME TO tablename;
COMMIT;
DROP delete_tablename;
> Just one thing would make it near perfect: if I could keep the master
> from being able to SELECT from the new child table while I'm COPYing
> data into the new child, building the index and vacuuming it - without
> sending an error back to the user who is querying the master table.
> 
> I tried a CHECK constraint, a RULE - SELECT rule can't INSTEAD DO
> NOTHING - #postgresql channel people say there's nothing that can do
> this... revoking privs or changing the owner of the new child results
> in an error back to the user who queries the master table. Tried
> creating a dummy table with no records and making a rule for the child
> to INSTEAD select from the dummy table but that was not allowed
> because it would turn my non-empty child table into a view.
> 
> Thank you,
> 
> - April
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-05-22 19:26:30 | Update on sort-compression stuff | 
| Previous Message | Jim C. Nasby | 2006-05-22 19:15:05 | Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?) |