But with the server running on one machine and the client running on
another, the two machines being connected by a 100 Mb ethernet, with nothing
else on the network, this test takes 17 minutes to run. I have tried
changing the frequency of COMMIT operations, but with only a small effect.
Are you
I don't think that's the advice being looked for here - if this
behaviour is repeatable, then there is something askew with the inet
protocol.
What is the client application written in? Do you know what version of
the postgres network protocol your driver code is using? Are the
inserts
On Thu, 2004-07-22 at 23:50, William Carney wrote:
Hello,
Using a test client application that performs 10 insert operations on a
table, with the client application running on the same machine as the
Postgres server, I get the following results for the time taken to run the
test:
I tested the LAN connection by transferring around some large (150 MByte)
files, and got consistent transfer rates of about 10 MBytes/second in both
directions without any problems, which is what I would expect. Netstat says
that there are no errors, so I think that the ethernet is working OK.
On Fri, 2004-07-23 at 01:50, William Carney wrote:
Hello,
Using a test client application that performs 10 insert operations on a
table, with the client application running on the same machine as the
Postgres server, I get the following results for the time taken to run the
test:
On Jul 23, 2004, at 3:57 AM, William Carney wrote:
I tested the LAN connection by transferring around some large (150
MByte)
files, and got consistent transfer rates of about 10 MBytes/second in
both
directions without any problems, which is what I would expect. Netstat
says
It would be
On Fri, Jul 23, 2004 at 03:20:54PM +0930, William Carney wrote:
But with the server running on one machine and the client running on
another, the two machines being connected by a 100 Mb ethernet, with nothing
else on the network, this test takes 17 minutes to run. I have tried
changing the
--- William Carney [EMAIL PROTECTED] wrote:
The test program is a C program with embedded SQL
(ecpg). The only
difference between the tests was the address used in
the EXEC SQL CONNECT
.. statement. The inserts are committed to the
database by performing an
EXEC SQL COMMIT after every N
William Carney [EMAIL PROTECTED] writes:
The machines used are P4s running FreeBSD 5.2.1. The Postgres version is
7.4.3. Can anyone tell me why there's such a big difference?
You're going to have to run tcpdump and see where the delays are. It might be
hard to decode the postgres protocol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Dennis Bjorklund [EMAIL PROTECTED] writes:
|
|In this plan it estimates to get 481 but it got 22477. So the estimation
|was very wrong. You can increase the statistics tarhet on the login_time
|and it will probably be better (after
Gaetano Mendola wrote:
Tom Lane wrote:
| Given the nature of the data (login times), I'd imagine that the problem
| is simply that he hasn't analyzed recently enough. A bump in stats
| target may not be needed, but he's going to have to re-analyze that
| column often if he wants this sort of
Hi all,
just as a question.
There will be some day a feature that let you force
the planner to use an specific index, like oracle
does?
Of course the planner is smart enough most times but
sometimes such an option would be usefull, don't you
think so?
Thanx in advance,
Jaime Casanova
On Fri, 2004-07-23 at 15:51, Jaime Casanova wrote:
Hi all,
just as a question.
There will be some day a feature that let you force
the planner to use an specific index, like oracle
does?
Of course the planner is smart enough most times but
sometimes such an option would be usefull,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew T. O'Connor wrote:
| Gaetano Mendola wrote:
|
| Tom Lane wrote:
| | Given the nature of the data (login times), I'd imagine that the
| problem
| | is simply that he hasn't analyzed recently enough. A bump in stats
| | target may not be needed,
Gaetano Mendola wrote:
Well I think pg_autovacuum as is in 7.4 can not help me for this particular
table.
The table have 4.8 milions rows and I have for that table almost 10252 new
entries for day.
I'm using pg_autovacuum with -a 200 -A 0.8 this means a threashold for
that table equal to: 3849008
15 matches
Mail list logo
