Here's what I do...
1) Install postgresql-libs from the RHEL source
2) Install compat-postgresql-libs from postgresql.org (install, not
upgrade, use rpm -hiv) use force if necessary
3) Install postgresq-libs from postgresql.org (again, install, not
upgrade, use rpm-hiv) use force if necessary
If I'm reading this correctly, 89% of the query time is spent
doing an index scan of earth_coords_idx. Scanning pets is only
taking 6% of the total time.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Stosberg
Sent: Tuesday, February 06, 2007 8:
ECTED]
Sent: Wednesday, January 17, 2007 3:29 PM
To: Adam Rich
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Configuration Advice
Adam Rich wrote:
> Doesn't sound like you want postgres at all Try mysql.
Could you explain your reason for suggesting mysql
Doesn't sound like you want postgres at all Try mysql.
-Original Message-
From: "Steve" <[EMAIL PROTECTED]>
To: pgsql-performance@postgresql.org
Sent: 1/17/2007 2:41 PM
Subject: [PERFORM] Configuration Advice
Hey there;
I've been lurking on this list awhile, and I've been working
Did anybody get a chance to look at this? Is it expected behavior?
Everyone seemed so incredulous, I hoped maybe this exposed a bug
that would be fixed in a near release.
-Original Message-
From: Adam Rich [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 07, 2007 11:53 PM
To: 'Jos
Each partition can have its own disk, without using subpartitions.
CREATE TABLE th (id INT, name VARCHAR(30), adate DATE)
PARTITION BY LIST(YEAR(adate))
(
PARTITION p1999 VALUES IN (1995, 1999, 2003)
DATA DIRECTORY = '/var/appdata/95/data'
INDEX DIRECTORY = '/var/appdata/95/idx',
PART
That query looks strange to me (a group by without an aggregate). See
if this is
any faster:
SELECT DISTINCT DATE(inserted) FROM Messages
I won't hold my breath though, I don't think there's any way around the
full table scan
in Postgres, because the index does not contain enough information a
otal runtime: 0.112 ms
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joshua D.
Drake
Sent: Sunday, January 07, 2007 9:10 PM
To: Adam Rich
Cc: 'Craig A. James'; 'Guy Rouillier'; 'PostgreSQL Performance'
Subject: Re: [PERFORM] Hi
_items
(cost=0.00..7986.82 rows=168196 width=8) (actual time=0.009..0.009
rows=1 loops=1)
Total runtime: 0.027 ms
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 07, 2007 8:48 PM
To: Adam Rich
Cc: 'Craig A. James'; 'Guy Rouillier&#
I'm using 8.2 and using order by & limit is still faster than MAX()
even though MAX() now seems to rewrite to an almost identical plan
internally.
Count(*) still seems to use a full table scan rather than an index scan.
Using one of our tables, MySQL/Oracle/MS-SQL all return instantly while
PG t
Dave,
Is it me or are the two examples you attached returning different row
counts?
That means either the source data is different, or your queries are.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Dutcher
Sent: Thursday, January 04, 2007 5:3
Craig,
What version of postgres are you using? I just tested this on PG 8.1.2
and was unable to reproduce these results. I wrote a simple function
that returns the same text passed to it, after sleeping for 1 second.
I use it in a where clause, like your example below, and regardless of
the numb
What are your table sizes? What are your queries like? (Mostly read,
mostly write?)
Can you post the "analyze" output for some of the slow queries?
The three things that stand out for me is your disk configuration (RAID
5 is not ideal for databases,
you really want RAID 1 or 1+0) and also tha
I have a table similar to this:
CREATE TABLE event_resources (
event_resource_id serial NOT NULL,
event_id integer NOT NULL,
resource_id integer NOT NULL,
start_date timestamptz NOT NULL,
end_date timestamptz NOT NULL,
CONSTRAINT event_resources_pkey PRIMARY KEY (event
14 matches
Mail list logo
