From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY Transform support |
Date: | 2008-04-07 18:44:41 |
Message-ID: | 812E5C0C-8353-446C-91EF-E990E2909444@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Apr 3, 2008, at 4:51 PM, Andrew Dunstan wrote:
> Several years ago Bruce and I discussed the then theoretical use of
> a SELECT query as the source for COPY TO, and we agreed that the
> sane analog would be to have an INSERT query as the target of COPY
> FROM.
>
> This idea seems to take that rather further. If doable I think it
> would be cool, as long as people don't try using it as an
> alternative storage engine. I can just imagine people creating
> views over such SELECT statements ...
Why not? There's certainly cases where doing just that could be very
valuable. Storing older information that you're less likely to query
comes to mind... in those cases you're going to be seqscanning
anyway, so being able to read off a compact on-disk form is likely to
be a win performance-wise. It could certainly be a win storage-wise.
If someone wants to look at syntax options, I'm pretty certain that
Oracle supports this. IIRC you actually create what appears to the
database to be a real table, except for restrictions on what you can
actually do with it (for example, IIRC it's read-only).
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-04-07 18:45:33 | File system snapshots for multiple file systems |
Previous Message | Joshua D. Drake | 2008-04-07 18:37:03 | Re: Feature freeze status |