[PERFORM] Implementatiion of Inheritance in Postgres

2004-07-07 Thread Ioannis Theoharis
I would like to ask you where i can find information about the implementation of the inheritance relationship in Postgres. There are several ways to store and to retrieve instances contained in an hierarchie. Which clustering and buffer replacement policy implements Postgres? There is a

[PERFORM] Terrible performance after deleting/recreating indexes

2004-07-07 Thread Bill Chandler
Hi, Using PostgreSQL 7.4.2 on Solaris. I'm trying to improve performance on some queries to my databases so I wanted to try out various index structures. Since I'm going to be running my performance tests repeatedly, I created some SQL scripts to delete and recreate various index

[PERFORM] inserting into brand new database faster than old database

2004-07-07 Thread Missner, T. R.
Hello, I have been a happy postgresql developer for a few years now. Recently I have discovered a very strange phenomenon in regards to inserting rows. My app inserts millions of records a day, averaging about 30 rows a second. I use autovac to make sure my stats and indexes are up to date.

[PERFORM] Forcing HashAggregation prior to index scan?

2004-07-07 Thread Eugene
I have a very simple problem. I run two select statments, they are identical except for a single where condition. The first select statment runs in 9 ms, while the second statment runs for 4000 ms SQL1 - fast 9ms explain analyse select seq_ac from refseq_sequence S where seq_ac in (select

Re: [PERFORM] Mysterious performance of query because of plsql function in

2004-07-07 Thread CoL
hi, Peter Alberer wrote: Hi there, i have a problem with a query that uses the result of a plsql function In the where clause: SELECT assignments.assignment_id, assignments.package_id AS package_id, assignments.title AS title, COUNT(*) AS Count FROM assignments INNER JOIN

[PERFORM] Odd sorting behaviour

2004-07-07 Thread Steinar H. Gunderson
[Please CC me on all replies, I'm not subscribed to this list] Hi, I'm trying to find out why one of my queries is so slow -- I'm primarily using PostgreSQL 7.2 (Debian stable), but I don't really get much better performance with 7.4 (Debian unstable). My prototype table looks like this:

[PERFORM] finding a max value

2004-07-07 Thread Edoardo Ceccarelli
This is the query: select max(KA) from annuncio field KA is indexed and is int4, explaining gives: explain select max(KA) from annuncio; QUERY PLAN --- Aggregate (cost=21173.70..21173.70 rows=1 width=4) - Seq Scan on annuncio

Re: [PERFORM] inserting into brand new database faster than old database

2004-07-07 Thread Missner, T. R.
I do have one table that acts as a lookup table and grows in size as the app runs, however in the tests I have been doing I have dropped and recreated all tables including the lookup table. I keep wondering how disk is allocated to a particular DB. Also is there any way I could tell whether the

Re: [PERFORM] finding a max value

2004-07-07 Thread Rosser Schwarz
On Fri, 02 Jul 2004 20:50:26 +0200, Edoardo Ceccarelli [EMAIL PROTECTED] wrote: This is the query: select max(KA) from annuncio wasn't supposed to do an index scan? it takes about 1sec to get the result. TIP 5: Have you checked our extensive FAQ? I believe this is a FAQ. See:

[PERFORM] query plan wierdness?

2004-07-07 Thread Joel McGraw
Can someone explain what I'm missing here? This query does what I expect--it uses the foo index on the openeddatetime, callstatus, calltype, callkey fields: elon2=# explain analyse select * from call where aspid='123C' and OpenedDateTime between '2000-01-01 00:00:00.0' and '2004-06-24

Re: [PERFORM] query plan wierdness?

2004-07-07 Thread Joel McGraw
Well, you're kind of right. I removed the limit, and now _both_ versions of the query perform a sequence scan! Oh, I forgot to include in my original post: this is PostgreSQL 7.3.4 (on x86 Linux and sparc Solaris 6) -Joel -Original Message- From: Guido Barosio [mailto:[EMAIL PROTECTED]

Re: [PERFORM] query plan wierdness?

2004-07-07 Thread Stephan Szabo
On Wed, 7 Jul 2004, Joel McGraw wrote: However, this query performs a sequence scan on the table, ignoring the call_idx13 index (the only difference is the addition of the aspid field in the order by clause): elon2=# explain analyse select * from call where aspid='123C' and OpenedDateTime