From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Bear Giles <bgiles(at)coyotesong(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: what would tar file FDW look like? |
Date: | 2015-08-17 14:29:58 |
Message-ID: | CAM-w4HM0t8us5pAXyOoeFoNGBmwcCTOhqzNvAYjMtm8sJKSxhA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 17, 2015 at 3:14 PM, Bear Giles <bgiles(at)coyotesong(dot)com> wrote:
> I'm starting to work on a tar FDW as a proxy for a much more specific FDW.
> (It's the 'faster to build two and toss the first away' approach - tar lets
> me get the FDW stuff nailed down before attacking the more complex
> container.) It could also be useful in its own right, or as the basis for a
> zip file FDW.
Hm. tar may be a bad fit where zip may be much easier. Tar has no
index or table of contents. You have to scan the entire file to find
all the members. IIRC Zip does have a table of contents at the end of
the file.
The most efficient way to process a tar file is to describe exactly
what you want to happen with each member and then process it linearly
from start to end (or until you've found the members you're looking
for). Trying to return meta info and then go looking for individual
members will be quite slow and have a large startup cost.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2015-08-17 14:33:20 | Re: Raising our compiler requirements for 9.6 |
Previous Message | Bear Giles | 2015-08-17 14:14:18 | what would tar file FDW look like? |