>Interesting. SQL Server -> Access is a done deal, so that is no problem.
>There are scripts already to move from Access -> PGSQL. (Not usually using
>ODBC; most instead generate an SQL dump, which you can then load. I think
>that's even nicer.)
>
>I guess it hangs on how much of the real stuff is
Mark kirkwood <[EMAIL PROTECTED]> writes:
> SELECT sum(val) FROM fact0
> I monitored the cpu consumed by the relevant db processes ( counting
> the time noted against each process from ps -ef, hope that was what
> you had in mind )
> DBElapsed Cpu
> Postgres 2m25s
x <[EMAIL PROTECTED]> writes:
> pqReadData() -- backend closed the channel unexpectedly.
That shouldn't happen :-(. Look for a core file in $PGDATA/base/yourdb/core
(if you don't find one, you probably need to restart the postmaster with
"ulimit -c unlimited" to allow core dumps). Then do
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Sometime ago somebody asked if it made a difference adn it was suggested
> that the effect was probably marginal. I ran a profiler over postgres doing
> a large query and these are the top 10 functions:
This is pretty meaningless when you didn'
x <[EMAIL PROTECTED]> writes:
> pqReadData() -- backend closed the channel unexpectedly.
> This probably means the backend terminated abnormally
> before or while processing the request.
> PQendcopy: resetting connection
>
> 3. I'm running the Windows/cygwin version of the psql
Hi.
I'm trying to run a script that executes multiple \copy commands in order
to import some 5 GB of data. All the input files are computer generated,
simple (5 numeric columns and "\N" for NULL in some cases), use default
delimiters, and _should_ be error free. But I keep getting error messag
