Hi,
i'm trying this too :). My Dump (IN) is about 84 minutes. Now
i'm testing how much time takes it with open_sync :). I'm
anxious about the new results :).
best regards,
pingufreak
Am Freitag, den 10.06.2005, 15:33 +0930 schrieb Steve Pollard:
> Hi All,
>
> Not sure if this is correct fix
Hi All,
Not sure if this is correct fix or not, but a bit of research :
http://archives.postgresql.org/pgsql-hackers/2001-04/msg01129.php
And offical doco's from postgres :
http://www.postgresql.org/docs/7.4/static/wal-configuration.html
Lead me to try :
wal_sync_method = open_sync
And this has in
Hi,
On Thu, Jun 09, 2005 at 02:11:22PM +0100, Richard Huxton wrote:
> >
> >To my question: I found the parameter "stats_reset_on_server_start"
> >which is set to true by default. Why did you choose this (and not false)
> >and what are the impacts of changeing it to false? I mean, as long as I
> >u
Hi Kevin,
Thanks for the reply.
I tried that query. It definately faster, but not fast enough (took
around 50 second to complete).
I have around 2.5 million on food and 1000 on person.
Here is the query plan:
QUERY PLAN
Hi Bruno,
I followed your suggestion.
The query plan shows that it uses the index (id, person_id). However,
the execution time is still slow. I have to do ctl-C to stop it.
Maybe something is wrong with my postgresql config.
It's running Solaris on dual Opteron, 4GB.
I allocated around 128MB for so
On 09/06/05, Matthew Nuzum ([EMAIL PROTECTED]) wrote:
> On 6/9/05, Rory Campbell-Lange <[EMAIL PROTECTED]> wrote:
> > Disks:
> >
> > I'm somewhat confused here. I've followed the various notes about SATA
> > vs SCSI and it seems that SCSI is the way to go. On a four-slot 1U
> > server, would one d
On 09/06/05, William Yu ([EMAIL PROTECTED]) wrote:
> Rory Campbell-Lange wrote:
> > ... Some have suggested that a single dual core processor is the way
> > to go. The RAM needs to fit the CPU arrangement too; William points
> > out that one needs 2 DIMMS per CPU.
> Your summary here just pointed
Rory Campbell-Lange wrote:
Processor:
First of all I noted that we were intending to use Opteron processors. I
guess this isn't a straightforward choice because I believe Debian (our
Linux of choice) doesn't have a stable AMD64 port. However some users on
this list suggest that Opterons work ver
[Jim C. Nasby - Thu at 01:04:53PM -0500]
> What does
>
> SET enable_seqscan = false;
> EXPLAIN ANALYZE SELECT * FROM ...
>
> get you? Is it faster?
I was experimenting with this some weeks ago, by now our database server has
quite low load numbers and I haven't gotten any complaints about anyth
What does
SET enable_seqscan = false;
EXPLAIN ANALYZE SELECT * FROM ...
get you? Is it faster?
BTW, I suspect this behavior is because the estimates for the cost of an
index scan don't give an appropriate weight to the correlation of the
index. The 'sort and index' thread on this list from a fe
On Thu, 2005-06-09 at 17:44 +0100, Rory Campbell-Lange wrote:
> Hi All. Thanks very much for Joshua, William, Bjoern and Matthew's
> replies.
>
> I've now looked at the famous "Server for 7K" thread. In my case we are
> looking for a server for around 3000 pounds (UK); the server is to be an
> all
On 6/9/05, Rory Campbell-Lange <[EMAIL PROTECTED]> wrote:
> Disks:
>
> I'm somewhat confused here. I've followed the various notes about SATA
> vs SCSI and it seems that SCSI is the way to go. On a four-slot 1U
> server, would one do a single RAID10 over 4 disks 1rpm U320 disks?
> I would run
Alex Stapleton <[EMAIL PROTECTED]> writes:
> Is this advisable?
Only if your database is small enough that you expect it to remain fully
cached in RAM. In that case random_page_cost = 1 does in fact describe
the performance you expect Postgres to see.
People occasionally use values for random_pa
Hi All. Thanks very much for Joshua, William, Bjoern and Matthew's
replies.
I've now looked at the famous "Server for 7K" thread. In my case we are
looking for a server for around 3000 pounds (UK); the server is to be an
all-purpose web and database server.
Processor:
First of all I noted that w
Is this advisable? The disks are rather fast (15k iirc) but somehow I
don't think they are covered in whatever magic fairy dust it would
require for a sequential read to be as fast as a random one. However
I could be wrong, are there any circumstances when this is actually
going to help per
Hi Tom,
Thank you for the input, you're absolutely right.
Have just executed like 10 VACUUM ANALYZE on the Price_Tbl in both
databases and now both queries use the same plan the bad one, GREAT!
Who said ignorance is bliss?? ;-)
Have just messed around with ALTER TABLE ... ALTER SET ST
We're hoping PostgreSQL can match or beat Sybase performance, and
preliminary tests look good. We should be able to get some load testing
going within a week, and we're shooting for slipping these machines into
the mix around the end of this month. (We've gone to some lengths to
keep our code po
Jona <[EMAIL PROTECTED]> writes:
> What worries me is that the plan is different,
Given that the estimated costs are close to the same, this is probably
just the result of small differences in the ANALYZE statistics leading
to small differences in cost estimates and thus choice of different
plans.
Thanks for your reply. Besides your post regarding *nix vs. Windows I
got a few which didn't go to the group. Words like "bold move" and
"disaster waiting to happen" tended to feature prominently in these
messages (regarding putting something this big on PostgreSQL under
Windows), and management
On 6/8/05, Francisco Figueiredo Jr. <[EMAIL PROTECTED]> wrote:
>
> --- Josh Close <[EMAIL PROTECTED]> escreveu:
>
> > Well, that would make total sense. I was kinda curious how the data
> > provider differentianted between :a and casting like now()::text.
> >
>
> Hi Josh!
>
> Npgsql uses the i
Thank you for the insight, any suggestion as to what table / columns I
should compare between the databases?
Cheers
Jona
Dennis Bjorklund wrote:
On Thu, 9 Jun 2005, Jona wrote:
It's the same (physical) server as well as the same PostGreSQL daemon,
so yes.
The only th
Yann Michel wrote:
To my question: I found the parameter "stats_reset_on_server_start"
which is set to true by default. Why did you choose this (and not false)
and what are the impacts of changeing it to false? I mean, as long as I
understood it, each query or statements generates some statistic
On Thu, 9 Jun 2005, Jona wrote:
> It's the same (physical) server as well as the same PostGreSQL daemon,
> so yes.
The only thing that can differ then is the statistics collected and the
amount of dead space in tables and indexes (but since you both reindex and
run vacuum full that should not be
Hi,
after having migrated a 7.2 pg-database to 7.4 while upgrdaing from
debian woody to debian sarge there are some more conf-Parameters to
evaluate.
We are running a small but continuously growing datawarehouse which has
recently around 40 million fact entries.
To my question: I found the para
It's the same (physical) server as well as the same PostGreSQL daemon,
so yes.
The only difference is the actual database, the test database is made
from a backup of the live database and restored onto the same PostGreSQL
server.
So if I run "show databases" in psql i get:
- test
- live
Make
Hi,
My Secenario :
P4 with 1G of memory on Fedora Core
about 100 inserts/update per hour
about 100 query per minute
20 concurrent connections
1. What is the best parameter setting in the pg_autovacuum
for my scenario ?
2. what will be my sleep setting if i want to
Is effective_cache_size set the same on the test and live?
Jona wrote:
Thanks... have notified our sys admin of that so he can make the correct
changes.
It still doesn't explain the difference in query plans though?
I mean, it's the same database server the two instances of the same
database
Thanks... have notified our sys admin of that so he can make the correct
changes.
It still doesn't explain the difference in query plans though?
I mean, it's the same database server the two instances of the same
database is running on.
One instance (the live) just insists on doing the seq sca
Thank you for the swift reply, the following is the output of the SHOW
ALL for shared_buffers and effective_cache_size.
shared_buffers: 13384
effective_cache_size: 4000
server memory: 2GB
effective_cache_size should be 10-100x larger perhaps...
Chris
---(end of bro
Kevin Grittner wrote:
The manager of the DBA team is reluctant to change both the OS and the
DBMS at the same time, so unless I can make a strong case for why it is
important to run postgresql under Linux, we will be running this on
Windows. Currently, there are two Java-based middle tier pro
Thank you for the swift reply, the following is the output of the SHOW
ALL for shared_buffers and effective_cache_size.
shared_buffers: 13384
effective_cache_size: 4000
server memory: 2GB
Please note, the databases are on the same server, it's merely 2
instances of the same database in order
On Thu, 9 Jun 2005 [EMAIL PROTECTED] wrote:
> I am continously encountering an issue with query plans that changes after
> a pg_dump / pg_restore operation has been performed.
>
> Have placed an export of the query, query plan etc. online at:
> http://213.173.234.215:8080/plan.htm in order to e
32 matches
Mail list logo