Jack Coates wrote:
latest changes:
shared_buffers = 35642
max_fsm_relations = 1000
max_fsm_pages = 1
wal_buffers = 64
sort_mem = 32768
vacuum_mem = 32768
effective_cache_size = 1
/proc/sys/kernel/shmmax = 5
IO is active, but hardly saturated. CPU load is hefty
On Friday 05 December 2003 02:07, Ivar Zarans wrote:
I have played around with explain and explain analyze and noticed one
interesting oddity:
[snip]
Why first example, where recid is given as numeric constant, is using
sequential scan, but second example, where recid is given as string
On Fri, Dec 05, 2003 at 10:08:20AM +, Richard Huxton wrote:
numeric constant must be typecasted in order to function properly.
Is this normal behaviour of fields with bigint type?
As Christopher says, normal (albeit irritating). Not sure it applies here -
all the examples you've
On Fri, Dec 05, 2003 at 06:19:46PM +0530, Shridhar Daithankar wrote:
is correct SQL, but not correct, considering PostgreSQL bugs.
Personally I don't consider a bug but anyways.. You are the one facing
problem so I understand..
Well, if this is not bug, then what is consideration behind
Ivar Zarans wrote:
On Fri, Dec 05, 2003 at 06:19:46PM +0530, Shridhar Daithankar wrote:
is correct SQL, but not correct, considering PostgreSQL bugs.
Personally I don't consider a bug but anyways.. You are the one facing
problem so I understand..
Well, if this is not bug, then what is
On Fri, 5 Dec 2003, Andrei Bintintan wrote:
There are around 700 rows in this table.
If I set enable_seqscan=off then the index is used and I also used Vacuum
Analyze recently.
I find it strange because the number of values of id_user and id_modull are
somehow in the same distribution and
On Fri, Dec 05, 2003 at 01:23:43PM +, Richard Huxton wrote:
Better IMHO would be: UPDATE table1 SET status = %s WHERE recid = %s::int8
Thanks for the hint!
unexpectedly in this scenario. The reason is that the literal number is
treated as int4, whereas quoted it is marked as type
I just spent 2 days tracking this error down in my own code, actually.
What I wound up doing is having the two places where I generate the
queries (everything in my system goes through those two points, as I'm
using a middleware layer) check values used as identifying fields for
the presence
Ivar Zarans wrote:
On Fri, Dec 05, 2003 at 01:23:43PM +, Richard Huxton wrote:
Better IMHO would be: UPDATE table1 SET status = %s WHERE recid = %s::int8
Thanks for the hint!
Which makes the wrapper class need:
def __str__( self ):
I need some help tracking down a sudden, massive slowdown
in inserts in one of our databases.
PG: 7.2.3 (RedHat 8.0)
Background. We currently run nearly identical systems
at two sites: Site A is a 'lab' site used for development,
Site B is a production site.
The databases in question have
Steve Wampler [EMAIL PROTECTED] writes:
PG: 7.2.3 (RedHat 8.0)
You're using PG 7.2.3 with the PG 7.1 JDBC driver; FWIW, upgrading to
newer software is highly recommended.
The two sites were performing at comparable speeds until a few days
ago, when we deleted several million records from
On Fri, 2003-12-05 at 09:26, Josh Berkus wrote:
Jack,
The frustrating thing is, we also have a UP P3-500 with 512M RAM and two
IDE drives with the same PG install which is doing okay with this load
-- still half the speed of MS-SQL2K, but usable. I'm at a loss.
Overall, I'm really
12 matches
Mail list logo
