It's more understandable if the table names are in front of the column
names :
SELECT relationship.topic_id1, relationship.topic_id2, topic.topic_name,
topic.categ_id, topic.list_name, topic.title,
topic.url, topic.page_type, relationship.rel_type, entry_type.inverse_id,
On Thu, Sep 29, 2005 at 07:59:34AM +0530, Rajesh Kumar Mallah wrote:
I see. These problems regularly come up in database design. The best thing
you can do is modify your database design/application such that instead of
incrementing a count in a single row, you insert a row into a table,
On Wed, Sep 28, 2005 at 06:03:03PM -0400, Ron Peacetree wrote:
1= keep more of the data set in RAM
2= increase the size of your HD IO buffers
3= make your RAID sets wider (more parallel vs sequential IO)
4= reduce the atomic latency of your RAID sets
(time for Fibre Channel 15Krpm HD's vs
On Thu, Sep 29, 2005 at 08:44:16AM -0400, Joe wrote:
CREATE TABLE entry (
entry_id serial PRIMARY KEY,
title VARCHAR(128) NOT NULL,
subtitle VARCHAR(128),
subject_type SMALLINT,
subject_id INTEGER REFERENCES topic,
actor_type SMALLINT,
actor_id INTEGER REFERENCES topic,
On Sat, Oct 01, 2005 at 12:51:08PM -0700, Roger Hand wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jim C. Nasby
Sent: Friday, September 30, 2005 4:49 PM
Subject: Re: [PERFORM] [HACKERS] Query in SQL statement
I suggest ditching the
On Thu, Sep 29, 2005 at 04:39:36PM -0400, Joe wrote:
Andreas Pflug wrote:
Hm, if you only have 4 tables, why do you need 12 queries?
To reduce queries, join them in the query; no need to merge them
physically. If you have only two main tables, I'd bet you only need 1-2
queries for the whole
There was a discussion about this about 2 months ago. See the archives.
On Mon, Oct 03, 2005 at 01:02:26PM +0200, Steinar H. Gunderson wrote:
I thought this might be interesting, not the least due to the extremely low
price ($150 + the price of regular DIMMs):
Hi Jim,
Jim C. Nasby wrote:
Also, just because no one else has mentioned it, remember that it's very
easy to get MySQL into a mode where you have no data integrity. If
that's the case it's going to be faster than PostgreSQL (though I'm not
sure how much that affects the performance of SELECTs).
On Tue, Oct 04, 2005 at 12:31:42PM +0200, Stefan Weiss wrote:
On 2005-09-30 01:21, Lane Van Ingen wrote:
(3) Assure that a disk-based table is always in memory (outside of keeping
it in
memory buffers as a result of frequent activity which would prevent
LRU
operations from
PFC wrote:
- if you use a version before 8, type mismatch will prevent use of the
indexes.
I'm using 8.0.3, but the type mismatch between relationship.rel_type and
entry_type.type_id was unintended. The current databases use SMALLINT for both.
The PostgreSQL schema was derived from an
On Thu, Sep 29, 2005 at 10:54:58PM +0300, [EMAIL PROTECTED] wrote:
Hi All,
I have a SQL function like :
CREATE OR REPLACE FUNCTION
fn_get_yetkili_inisyer_listesi(int4, int4)
RETURNS SETOF kod_adi_liste_type AS
$BODY$
SELECT Y.KOD,Y.ADI
FROM T_YER Y
WHERE EXISTS
On Fri, Sep 23, 2005 at 08:17:03PM +0800, K C Lau wrote:
esdt= create or replace function player_max_atdate (varchar(32)) returns
varchar(32) as $$
esdt$ select distinct on (PlayerID) AtDate from player where PlayerID= $1
order by PlayerID desc, AtDate desc limit 1;
esdt$ $$ language sql
Jim C. Nasby wrote:
Make sure these indexes exist if you'll be updating or inserting into
entry:
CREATE INDEX topic__subject_id ON topic(subject_id);
CREATE INDEX topic__actor_id ON topic(actor_id);
Actually, topic's primary key is topic_id.
Also, the fact that subject and actor both point
On Fri, Sep 23, 2005 at 04:53:55PM +0800, K C Lau wrote:
Thank you all for your suggestions. I' tried, with some variations too, but
still no success. The times given are the best of a few repeated tries on
an 8.1 beta 2 db freshly migrated from 8.0.3 on Windows.
For reference, only the
On Tue, Oct 04, 2005 at 05:11:19PM -0400, Joe wrote:
Hi Jim,
Jim C. Nasby wrote:
Also, just because no one else has mentioned it, remember that it's very
easy to get MySQL into a mode where you have no data integrity. If
that's the case it's going to be faster than PostgreSQL (though I'm
On Tue, Oct 04, 2005 at 04:15:41PM -0500, Jim C. Nasby wrote:
Index Cond: ((playerid)::text = '0'::text)
Also, why is playerid a text field? Comparing ints will certainly be
faster...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
Which version of PG are you using? One of the new features for 8.0 was
an improved caching algorithm that was smart enough to avoid letting a
single big query sweep everything else out of cache.
-- Mark Lewis
On Tue, 2005-10-04 at 10:45 -0400, Lane Van Ingen wrote:
Yes, Stefan, the kind of
Postgresql uses MVCC to ensure data integrity. Server must choose the right
version of tuple, according to transaction ID of statement. Even for a
select (ACID features of postgresql, I think C and I apply here), it must
accomplish some extra work.
-Mensaje original-
De: [EMAIL PROTECTED]
pg is _very_ stupid about caching. Almost all of the caching is left
to the OS, and it's that way by design (as post after post by TL has
pointed out).
That means pg has almost no ability to take application domain
specific knowledge into account when deciding what to cache.
There's plenty of
On Tue, Oct 04, 2005 at 07:33:47PM -0400, Ron Peacetree wrote:
pg is _very_ stupid about caching. Almost all of the caching is left
to the OS, and it's that way by design (as post after post by TL has
pointed out).
That means pg has almost no ability to take application domain
specific
Ron Peacetree sounds like someone talking out of his _AZZ_.
He can save his unreferenced flapdoodle for his SQL Server
clients. Maybe he will post references so that we may all
learn at the feet of Master Peacetree. :-)
douglas
On Oct 4, 2005, at 7:33 PM, Ron Peacetree wrote:
pg is
I have an application that has a table that is both read and write intensive.
Data from iostat indicates that the write speed of the system is the factor
that is limiting performance. The table has around 20 columns and most of the
columns are indexed. The data and the indices for the table
Douglas J. Trainor wrote:
Ron Peacetree sounds like someone talking out of his _AZZ_.
He can save his unreferenced flapdoodle for his SQL Server
clients. Maybe he will post references so that we may all
learn at the feet of Master Peacetree. :-)
Although I agree that I would definitely
Unfortunately, no matter what I say or do, I'm not going to please
or convince anyone who has already have made their minds up
to the extent that they post comments like Mr Trainor's below.
His response style pretty much proves my earlier point that this
is presently a religious issue within the
Talk about your IO system a bit. There might be obvious ways to improve.
What System/Motherboard are you using?
What Controller Cards are you using?
What kind of Disks do you have (SATA, SCSI 7.6k 10k 15k)
What denominations (9, 18, 36, 72, 143, 80, 160, 200 240Gig)?
What kind of RAIDs do you
Talk about your IO system a bit. There might be obvious ways to improve.
What System/Motherboard are you using?
What Controller Cards are you using?
What kind of Disks do you have (SATA, SCSI 7.6k 10k 15k)
What denominations (9, 18, 36, 72, 143, 80, 160, 200 240Gig)?
What kind of RAIDs do
On Tue, Oct 04, 2005 at 11:06:54PM -0400, Ron Peacetree wrote:
Some might even argue that IBM (where Codd and Date worked)
and Oracle just _might_ have had justification for the huge effort
they put into developing such infrastructure.
The OS and FS world is very, very different now than it
On Tue, Oct 04, 2005 at 11:06:54PM -0400, Ron Peacetree wrote:
Unfortunately, no matter what I say or do, I'm not going to please
or convince anyone who has already have made their minds up
to the extent that they post comments like Mr Trainor's below.
His response style pretty much proves my
28 matches
Mail list logo
