Mark Woodward wrote:
>> Mark Woodward wrote:
>>> This runs completely in the background and can serve as a running
>> And you are sure it would be much faster then a server local running
>> psql just dumping the result of a query?
> No I can't be sure of that at all, but .... The COPY command has a
> specific use that is understood and an operation that is separate from the
> normal query mechanism.
Unless you change it to actually execute a query ;)
>> (And you could more easy avoid raceconditions in contrast to several
>> remote clients trying to trigger your above backup )
> Again, the examples may not have been precise in presenting "why," the
> focus was mostly "what" so it could be discussed. As a generic feature it
> has many potential uses. Trying to debate and defend a specific use limits
> the potential scope of the feature.
Thats why I'm asking. I'm still wondering which use-case actually
defends the integration of the resultset-formatter into the backend
vs. just doing it in the frontend (in both places there are already
some routines which could be used to implent).
> Why have COPY anyway? Why not just use "SELECT * FROM TABLE?"
Because the special SELECT * FROM TABLE can be optimized aparently.
Ah yes, and if usual result fetch requires storing result set
in server ram, it would be nicer to change that if possible.
I think we run SELECT ... much more often then COPY ;-)
(And I hope nobody comes up with the idea if copy would be implemented
to execute queries, to generally use COPY instead of select for
large result sets in applications. Goodbye portability...)
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2006-06-03 15:27:03|
|Subject: Re: Faster Updates |
|Previous:||From: PFC||Date: 2006-06-03 15:12:14|
|Subject: Faster Updates|