From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: COPY enhancements |
Date: | 2009-09-12 15:44:01 |
Message-ID: | 4AABC1C1.20205@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Right. What I proposed would not have been terribly invasive or
>> difficult, certainly less so than what seems to be our direction by an
>> order of magnitude at least. I don't for a moment accept the assertion
>> that we can get a general solution for the same effort.
>>
>
> And at the same time, Greg's list of minimum requirements was far
> longer than what you proposed to do. We can *not* just implement
> those things one at a time with no thought towards what the full
> solution looks like --- at least not if we want the end result to
> look like it was intelligently designed, not merely accreted.
>
>
>
I don't disagree with that.
At the same time, I think it's probably not a good thing that users who
deal with very large amounts of data would be forced off the COPY fast
path by a need for something like input support for non-rectangular
data. It probably won't affect my clients too much in this instance, but
then their largest loads are usually of the order of only 50,000 records
or so. I understand Truviso has handled this by a patch that does the
sort of stuff Greg was talking about.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-12 15:53:35 | Re: drop tablespace error: invalid argument |
Previous Message | Tom Lane | 2009-09-12 15:23:57 | Re: COPY enhancements |