Re: [PERFORM] Please Help: PostgreSQL performance Optimization

2006-01-13 Thread Jamal Ghaffour
Andrew Lazarus a écrit : Jamal Ghaffour wrote: CREATE TABLE cookies ( domain varchar(50) NOT NULL, path varchar(50) NOT NULL, name varchar(50) NOT NULL, principalid varchar(50) NOT NULL, host text NOT NULL, value text NOT NULL, secure bool NOT NULL, timestamp timestamp

Re: [PERFORM] Please Help: PostgreSQL performance Optimization

2006-01-13 Thread Frank Wiles
On Thu, 12 Jan 2006 01:32:10 +0100 Jamal Ghaffour [EMAIL PROTECTED] wrote: I'm using the default configuration file, and i m asking if i have to change some paramters to have a good performance. In general the answer is yes. The default is a pretty good best guess at what sorts of values

[PERFORM] insert without oids

2006-01-13 Thread Michael Stone
OIDs seem to be on their way out, and most of the time you can get a more helpful result by using a serial primary key anyway, but I wonder if there's any extension to INSERT to help identify what unique id a newly-inserted key will get? Using OIDs the insert would return the OID of the inserted

Re: [PERFORM] insert without oids

2006-01-13 Thread Michael Fuhr
On Fri, Jan 13, 2006 at 03:10:11PM -0500, Michael Stone wrote: Are there plans on updating the insert API for the post-OID world? Are you looking for this TODO item? * Allow INSERT/UPDATE ... RETURNING new.col or old.col This is useful for returning the auto-generated key for an INSERT.

Re: [PERFORM] insert without oids

2006-01-13 Thread Neil Conway
On Fri, 2006-01-13 at 15:10 -0500, Michael Stone wrote: OIDs seem to be on their way out, and most of the time you can get a more helpful result by using a serial primary key anyway, but I wonder if there's any extension to INSERT to help identify what unique id a newly-inserted key will get?

Re: [PERFORM] insert without oids

2006-01-13 Thread Michael Stone
On Fri, Jan 13, 2006 at 04:29:15PM -0500, Neil Conway wrote: There's really no additional operations required: INSERT INTO t2 VALUES (currval('t1_id_seq'), ...); You need a separate SELECT if you want to use the generated sequence value outside the database, That would, of course, be the

Re: [PERFORM] Slow query with joins

2006-01-13 Thread Jim C. Nasby
On Wed, Jan 11, 2006 at 10:30:58PM +0100, Bendik Rognlien Johansen wrote: The sort is definitively the culprit. When I removed it the query was instant. I tried setting work_mem = 131072 but it did not seem to help. I really don't understand this :-( Any other ideas? What's explain analyze

Re: [PERFORM] Stable function being evaluated more than once in a single query

2006-01-13 Thread Jim C. Nasby
On Wed, Jan 11, 2006 at 11:33:23PM -0500, Tom Lane wrote: Mark Liberman [EMAIL PROTECTED] writes: I've got a set-returning function, defined as STABLE, that I reference twice within a single query, yet appears to be evaluated via two seperate function scans. There is no

Re: [PERFORM] Throwing unnecessary joins away

2006-01-13 Thread Jim C. Nasby
On Thu, Jan 12, 2006 at 01:35:07PM +0100, Alessandro Baretta wrote: Ott? Havasv?lgyi wrote: Hi all, Is PostgreSQL able to throw unnecessary joins? For example I have two tables, and I join then with their primary keys, say type of bigint . In this case if I don't reference to one of the

Re: [PERFORM] Throwing unnecessary joins away

2006-01-13 Thread Jim C. Nasby
On Thu, Jan 12, 2006 at 07:51:22PM +0100, Ott? Havasv?lgyi wrote: Hi, If the join is to a primary key or notnull unique column(s), then inner join is also ok. But of course left join is the simpler case. An example: Actually, you need both the unique/pk constraint, and RI (a fact I missed

Re: [PERFORM] Stable function being evaluated more than once in a single query

2006-01-13 Thread Tom Lane
Jim C. Nasby [EMAIL PROTECTED] writes: Is the issue that the optimizer won't combine two function calls (ie: SELECT foo(..) ... WHERE foo(..)), or is it that sometimes it won't make the optimization (maybe depending on the query plan, for example)? What the STABLE category actually does is

Re: [PERFORM] Stable function being evaluated more than once in a single query

2006-01-13 Thread Jim C. Nasby
Adding -docs... On Fri, Jan 13, 2006 at 07:27:28PM -0500, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Is the issue that the optimizer won't combine two function calls (ie: SELECT foo(..) ... WHERE foo(..)), or is it that sometimes it won't make the optimization (maybe depending

Re: [PERFORM] Extremely irregular query performance

2006-01-13 Thread Bruce Momjian
Jean-Philippe Cote wrote: Can I actully know whether a given plan is excuted with GEQO on ? In other words, if I launch 'explain query', I'll get a given plan, but if I re-launch the query (withtout the 'explain' keyword), could I get a different plan given that GEQO induces some

[PERFORM] Hanging Query

2006-01-13 Thread vimal . gupta
We have to inserts a records(15000- 2) into a table which also contains (15000-2) records, then after insertion, we have to delete the records according to a business rule. Above process is taking place in a transaction and we are using batches of 128 to insert records. Everything works

[PERFORM] = forces row compare and not index elements compare when possible

2006-01-13 Thread Bernard Dhooghe
Suppose a table with structure: Table public.t4 Column | Type | Modifiers +---+--- c1 | character(10) | not null c2 | character(6) | not null c3 | date | not null c4 | character(30) | c5 | numeric(10,2) | not null Indexes:

[PERFORM] Extremely irregular query performance

2006-01-13 Thread Jean-Philippe Côté
Hi, I'm running version 8.1 on a dedicated Sun v20 server (2 AMD x64's) with 4Gb of RAM. I have recently noticed that the performance of some more complex queries is extremely variable and irregular. For example, I currently have a query that returns a small number of rows (5) by joining a

[PERFORM] Postgres8.0 Planner chooses WRONG plan.

2006-01-13 Thread Pallav Kalva
Hi , I am having problem optimizing this query, Postgres optimizer uses a plan which invloves seq-scan on a table. And when I choose a option to disable seq-scan it uses index-scan and obviously the query is much faster. All tables are daily vacummed and analyzed as per docs. Why

Re: [PERFORM] Extremely irregular query performance

2006-01-13 Thread Kenneth Marshall
On Thu, Jan 12, 2006 at 09:48:41AM +, Simon Riggs wrote: On Wed, 2006-01-11 at 22:23 -0500, Tom Lane wrote: =?iso-8859-1?Q?Jean-Philippe_C=F4t=E9?= [EMAIL PROTECTED] writes: Thanks a lot for this info, I was indeed exceeding the genetic optimizer's threshold. Now that it is turned

Re: [PERFORM] Extremely irregular query performance

2006-01-13 Thread Kenneth Marshall
On Thu, Jan 12, 2006 at 03:23:14PM -0500, Jean-Philippe Cote wrote: Can I actully know whether a given plan is excuted with GEQO on ? In other words, if I launch 'explain query', I'll get a given plan, but if I re-launch the query (withtout the 'explain' keyword), could I get a different