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 when I search the table the id_user
index is used bu
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.
For 700 rows I think seq. would work best.
I find it strange because the number of values of id_user and id_modull are
somehow in the same di
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
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
> c
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 y
Ivar Zarans wrote:
It seems, that PyPgSQL query quoting is not aware of this performance
problem (to which Cristopher referred) and final query, sent to server
is correct SQL, but not correct, considering PostgreSQL bugs.
Personally I don't consider a bug but anyways.. You are the one facing proble
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 behin
On Friday 05 December 2003 12:49, Shridhar Daithankar wrote:
> Ivar Zarans wrote:
> > It seems, that PyPgSQL query quoting is not aware of this performance
> > problem (to which Cristopher referred) and final query, sent to server
> > is correct SQL, but not correct, considering PostgreSQL bugs.
>
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 considerat
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
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 un
On Fri, Dec 05, 2003 at 07:21:38PM +0530, Shridhar Daithankar wrote:
> planner consider seemingly same type as different. e.g. treating int8 as
> different than int4. Obvious thinking is they should be same. But given
> postgresql's flexibility with create type, it is difficult to promote.
OK,
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 o
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 ):
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 getting the feeling that this procedure was optimized for
Ivar Zarans <[EMAIL PROTECTED]> writes:
> > qry = "UPDATE table1 SET status = %s WHERE recid = '%s'"
> > cursor.execute(qry, status, recid)
>
> Yes, this helps. But then it sort of obsoletes PyPgSQL-s own quoting
> logic. I would prefer to take care of this all by myself or trust some
> underlyin
Ace's Hardware has put together a fairly comprehensive comparison
between Xeon & Opteron platforms running server apps. Unfortunately,
only MySQL "data mining" benchmarks as the review crew doesn't have that
much experience with OLTP-type systems but I'm gonna try to convince
them to add the OD
Hello,
I use php as front-end to query our database. When I use System Monitor to check the
usage of cpu and memory, I noticed that the cpu very easily gets up to 100%. Is that
normal? if not, could someone points out possible reason?
I am using linux7.3, pgsql 7.3.4, 1G Memory and 2GHz CPU.
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 ide
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 re
On Friday 05 December 2003 16:51, Steve Wampler wrote:
> 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
22 matches
Mail list logo
