Greetings all,
I am continously encountering an issue with query plans that changes after
a pg_dump / pg_restore operation has been performed.
On the production database, PostGre refuses to use the defined indexes in
several queries however once the database has been dumped and restored
either
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
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
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
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
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
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
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
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
Makes
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
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
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
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 info found in
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 is
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.
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
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
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 we
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
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 the
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
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
[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 anything
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
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 out
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 do a single
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
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,
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
understood
29 matches
Mail list logo
