Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: BUG #4559: performance issue


  • From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
  • To: "M. Alaa ElGohary" <alaa(dot)elgohary(at)backandfront(dot)ws>
  • Cc: pgsql-bugs(at)postgresql(dot)org
  • Subject: Re: BUG #4559: performance issue
  • Date: Fri, 19 Dec 2008 10:22:46 +0900
  • Message-id: <494AF766.8090808@postnewspapers.com.au> <text/plain>

M. Alaa ElGohary wrote:
> The following bug has been logged online:
> 
> Bug reference:      4559
> Logged by:          M. Alaa ElGohary
> Email address:      alaa(dot)elgohary(at)backandfront(dot)ws
> PostgreSQL version: 7.4.19
> Operating system:   FreeBSD 6.3
> Description:        performance issue
> Details: 
> 
> I have a POS application that performs end of day process in which data is
> transfered from a set of tables to another this process stops completely
> with no reason when i make a dump of the database and drop then create and
> restore the dump the end of day process performs extremely fast with no
> stopage
> i need to know whats the reason that stops this process and why is it
> overcome when i drop and restore the database and how can i solve this
> without needing to drop and restore the database
> thanks

This is not a bug report. You haven't explained what, exactly,
PostgreSQL is doing wrong, nor have you provided any examples or any way
for anybody else to understand the problem.

I suggest posting a more detailed question to the pgsql-general mailing
list. Include examples and a step-by-step explanation of what happens.
Mention your Pg version and other things people need to know. It's also
likely to help if you punctuate your question so that people can follow
what you are saying; I found your writing very difficult to understand.

--
Craig Ringer



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group