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. May
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 interest
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 th
--- 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 e
"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 protoco
-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 (afte
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 query
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 us
-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 nee
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
12 matches
Mail list logo
