On Oct 15, 2006, at 8:23 PM, Joby Walker wrote:
As was pointed out to me the current value function returns the
last value used for that connection, so from the pgsql side it is
multithread safe -- but I don't know how using a connection pooling
system like SQLRelay impacts things
Vivek Khera wrote:
On Oct 13, 2006, at 6:48 PM, Joby Walker wrote:
OIDs were used to get the id of the last insert. The was abandoned
because of pgsql 8.1, but it was a horrible way to get the last id
anyway. Current versions of SB insert the row and then get the
current value of the
On Oct 13, 2006, at 6:48 PM, Joby Walker wrote:
OIDs were used to get the id of the last insert. The was abandoned
because of pgsql 8.1, but it was a horrible way to get the last id
anyway. Current versions of SB insert the row and then get the
current value of the sequence associated
I recall that we made a major pg-related fix around 3.4.2 or so. If you
suspect it's postgres-side stuff that's slowing you down, turning on the
query log and seeing if you can reindex a bit is worthwhile.
I've moved to 3.4.5 but it still seems slow to me.
You're talking about the postgresql
On Fri, 2006-10-13 at 08:07 -0500, Kenneth Marshall wrote:
CREATE INDEX attachmentsoid ON attachments USING btree ( oid );
CREATE INDEX cachedgroupmembersoid ON cachedgroupmembers USING btree ( oid );
CREATE INDEX objectcustomfieldvaluesoid ON objectcustomfieldvalues USING
btree ( oid );
On Oct 13, 2006, at 9:07 AM, Kenneth Marshall wrote:
Here are the indexes that needed to be added to the DB to enable fast
OID based queries. Hopefully, they can be included in 3.6.2+.
CREATE INDEX attachmentsoid ON attachments USING btree ( oid );
CREATE INDEX cachedgroupmembersoid ON
On Oct 13, 2006, at 9:32 AM, Dmitri Tikhonov wrote:
Here's also a post from two years ago that still applies to 3.4.5:
http://lists.bestpractical.com/pipermail/rt-devel/2004-September/
006273.html
I still use them in RT 3.6, too :-)
smime.p7s
Description: S/MIME cryptographic
On Oct 13, 2006, at 12:18 AM, Jesse Vincent wrote:
Strongly recommend:
* newer RT
* newer Pg (8.x before 8.1.4 had some specialness)
* vacuum analyzing your postgres instance.
Also make sure your Pg is tuned properly for the size of your DB.
See recent discussion
On Fri, Oct 13, 2006 at 10:44:57AM -0400, Vivek Khera wrote:
On Oct 13, 2006, at 9:07 AM, Kenneth Marshall wrote:
Here are the indexes that needed to be added to the DB to enable fast
OID based queries. Hopefully, they can be included in 3.6.2+.
CREATE INDEX attachmentsoid ON
On Oct 13, 2006, at 10:53 AM, Kenneth Marshall wrote:
to 3.6.x. This is with an older version of searchbuilder (1.36) on
the 3.4.5 system. We could not upgrade to a newer version because it
caused our DB queries to fail. Do you think that it is safe to remove
the oid column?
If you do a
Thank you everybody for the suggestions.
I will look into adding the suggested indexes, and look at my RAM usage.
I think I need to get more than 1GB of RAM on the box, so I have room
to play. Those httpd processes end up taking a lot of RAM.
I'll also work on moving up to Pg 8.1.4, and
OIDs were used to get the id of the last insert. The was abandoned
because of pgsql 8.1, but it was a horrible way to get the last id
anyway. Current versions of SB insert the row and then get the current
value of the sequence associated with that table. This is much faster
and *should* be
We have an install of RT running on Linux/PostgreSQL, and it seems slow
to me.
For example, if I just bring up a ticket:
http://xxx/index.html?q=58431
the little Time to display can be anywhere between 3.6 and 8. It tends
to the longer side of things.
My overall question is: what's good?
On Thu, Oct 12, 2006 at 11:51:52PM -0400, Kevin White wrote:
The production server is running Centos 4 (RHEL 4) on a machine that
really doesn't have enough RAM (1GB) and only has IDE disks, running as
a software RAID1. It IS an Opteron, and it is running 64-bit. rt 3.4.1
and
Jesse Vincent wrote:
On Thu, Oct 12, 2006 at 11:51:52PM -0400, Kevin White wrote:
The production server is running Centos 4 (RHEL 4) on a machine that
really doesn't have enough RAM (1GB) and only has IDE disks, running as
a software RAID1. It IS an Opteron, and it is running 64-bit. rt
On Fri, Oct 13, 2006 at 12:22:36AM -0400, Kevin White wrote:
Jesse Vincent wrote:
On Thu, Oct 12, 2006 at 11:51:52PM -0400, Kevin White wrote:
The production server is running Centos 4 (RHEL 4) on a machine that
really doesn't have enough RAM (1GB) and only has IDE disks, running as
16 matches
Mail list logo
