scott.marlowe wrote:
On Fri, 23 Apr 2004, Chris Hoover wrote:
DB's on Powervaults 220S using raid 5 (over 6 disks)
What controller is this, the adaptec? We've found it to be slower than
the LSI megaraid based controller, but YMMV.
Wow, really? You got any more details of the chipset, mobo and
On Wed, Apr 21, 2004 at 02:51:31PM -0400, Tom Lane wrote:
The context swap storm is happening because of contention at the next
level up (LWLocks rather than spinlocks). It could be an independent
issue that just happens to be triggered by the same sort of access
pattern. I put forward a
Hi,
I have a query which I think should be using an index all of the time but
postgres only uses the index part of the time. The index
(ticket_crm_map_crm_id_suppid) has the where clause column (crm_id) listed
first followed by the selected column (support_person_id). Wouldn't the
most
Hello,
I have recently configured my PG7.3 on a G5 (8GB RAM) with
shmmax set to 512MB and shared_buffer=5, sort_mem=4096
and effective cache size = 1. It seems working great so far but
I am wondering if I should make effctive cache size larger myself.
Tnaks!
Qing
On Apr 21, 2004, at 9:29
hi,
Sean Shanny wrote, On 4/22/2004 23:56:
SELECT t1.id, t2.url FROM referral_temp t2 LEFT OUTER JOIN d_referral t1
ON t2.url = t1.referral_raw_url ORDER BY t1.id
index on url (text) has no sense. Try to use and md5 (char(32) column)
which contains the md5 hash of url field. and join these ones.
Ok, I was able to run a vacuumdb -f -v on my largest db over the weekend.
However, I am having trouble reading the results of the table portion. Here
area a couple of tables, what should I be looking at. First table is the key
table to the db, and the second is the largest table in the db.
Hi,
I have a query which I think should be using an index all of the time but
postgres only uses the index part of the time. The index
(ticket_crm_map_crm_id_suppid) has the where clause column (crm_id) listed
first followed by the selected column (support_person_id). Wouldn't the
most
When checking an index in postgres the original table has to be checked for
each result to find if the index entry is still valid? In which case you
can't blindly scan the whole index and assume the data is good. I was used
to Oracle behavior where the index is up to date so it can do the scan
Magus,
It would be interesting to see what a locking implementation ala FUTEX
style would give on an 2.6 kernel, as i understood it that would work
cross process with some work.
I'mm working on testing a FUTEX patch, but am having some trouble with it.
Will let you know the results
Dave,
Yeah, I did some more testing myself, and actually get better numbers
with increasing spins per delay to 1000, but my suspicion is that it is
highly dependent on finding the right delay for the processor you are
on.
Well, it certainly didn't help here:
procs
Are you testing this with Tom's code, you need to do a baseline
measurement with 10 and then increase it, you will still get lots of cs,
but it will be less.
Dave
On Mon, 2004-04-26 at 20:03, Josh Berkus wrote:
Dave,
Yeah, I did some more testing myself, and actually get better numbers
Rod Taylor [EMAIL PROTECTED] wrote:
On Thu, 2004-04-22 at 07:02, Michiel Meeuwissen wrote:
Rod Taylor [EMAIL PROTECTED] wrote:
The scan is picking the best method for grabbing everything within the
table, since it is not aware that we do not require everything.
Hmm. That is a bit
Rod Taylor [EMAIL PROTECTED] wrote:
The scan is picking the best method for grabbing everything within the
table, since it is not aware that we do not require everything.
Hmm. That is a bit silly. Why does it use the index if select only from
mm_mediasources?
You can explicitly tell it what
I am using the oid of the table as the main key and I've found that is
not indexed (maybe because I have declared another primary key in the table)
it is a good practice to create an index like this on the oid of a table?
CREATE INDEX idoid annuncio400 USING btree (oid);
does it work as a normal
Yes, you can create an index on the oid, but unless you are selecting on
it, it is of little use.
you would have to do select * from foo where oid=? to get any value out
of the index.
Dave
On Mon, 2004-04-26 at 12:38, Edoardo Ceccarelli wrote:
I am using the oid of the table as the main key and
I am using the oid of the table as the main key and I've found that is
not indexed (maybe because I have declared another primary key in the
table)
it is a good practice to create an index like this on the oid of a table?
CREATE INDEX idoid annuncio400 USING btree (oid);
Yes it is - in fact you
16 matches
Mail list logo
