[PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread Віталій Тимчишин
Hello. It's second query rewrite postgresql seems not to handle - making EXCEPT from NOT IT. Here is an example: Preparation: drop table if exists t1; drop table if exists t2; create temporary table t1(id) as select (random()*10)::int from generate_series(1,20) a(id); create temporary ta

Re: [PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread DANIEL CRISTIAN CRUZ
Something weird with your example which doesn't have the same result, see row count with explain analyze: cruz=# SELECT version(); version -

Re: [PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread Alvaro Herrera
Віталій Тимчишин escribió: > So the question is: I am willing to participate in postgresql development > because it may be easier to fix planner then to rewrite all my queries :). > How can I? (I mean to work on query planner enhancements by providing new > options of query rewrite, not to work on

Re: [PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread Віталій Тимчишин
2008/11/19 Stephan Szabo <[EMAIL PROTECTED]> > > On Wed, 19 Nov 2008, [ISO-8859-5] Віталій Тимчишин wrote: > > > Query 1: > > select * from t1 where id not in (select id from t2); > > > > Query 2 (gives same result as Q1): > > select * from t1 except all (select id from t2); > > It gives the same

Re: [PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread Stephan Szabo
On Wed, 19 Nov 2008, [ISO-8859-5] ??? wrote: > Query 1: > select * from t1 where id not in (select id from t2); > > Query 2 (gives same result as Q1): > select * from t1 except all (select id from t2); It gives the same result as long as no nulls are in either table. If either table

Re: [PERFORM] PostgreSQL NOT IN performance

2008-11-19 Thread Віталій Тимчишин
2008/11/19 DANIEL CRISTIAN CRUZ <[EMAIL PROTECTED]> > Something weird with your example which doesn't have the same result, see > row count with explain analyze: > My fault. EXCEPT ALL would not work here, so this method with EXCEPT can be used only when either operation is done on unique key on t

[PERFORM] Very Urgent : Sequences Problem

2008-11-19 Thread Kranti™ K K Parisa
Hi, I have defined sequence on a table something like this CREATE SEQUENCE items_unqid_seq INCREMENT 1 MINVALUE 0 MAXVALUE 9223372036854775807 START 7659 CACHE 1; this is on a table called items. where i have currently the max(unq_id) as 7659. and in the stored procedure when i am in

Re: [PERFORM] Very Urgent : Sequences Problem

2008-11-19 Thread Josh Berkus
Kranti (tm), If you problem is very urgent, I suggest that you get a paid support contract with a PostgreSQL support company. You can find a list of support companies here: http://www.postgresql.org/support/professional_support These mailing lists are made up of other PostgreSQL users and

Re: [PERFORM] Very Urgent : Sequences Problem

2008-11-19 Thread Merlin Moncure
On Wed, Nov 19, 2008 at 10:54 AM, Kranti™ K K Parisa <[EMAIL PROTECTED]> wrote: > Hi, > > I have defined sequence on a table something like this > > > CREATE SEQUENCE items_unqid_seq > INCREMENT 1 > MINVALUE 0 > MAXVALUE 9223372036854775807 > START 7659 > CACHE 1; > > this is on a table c

Re: [PERFORM] Very Urgent : Sequences Problem

2008-11-19 Thread tv
> On Wed, Nov 19, 2008 at 10:54 AM, Kranti� K K Parisa > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I have defined sequence on a table something like this >> >> >> CREATE SEQUENCE items_unqid_seq >> INCREMENT 1 >> MINVALUE 0 >> MAXVALUE 9223372036854775807 >> START 7659 >> CACHE 1; >> >> thi

[PERFORM] Hash join on int takes 8..114 seconds

2008-11-19 Thread Andrus
Query below seems to use indexes everywhere in most optimal way. dokumnr column is of type int Speed of this query varies rapidly: In live db fastest response I have got is 8 seconds. Re-running same query after 10 seconds may take 60 seconds. Re-running it again after 10 seconds may take 114 s

Re: [PERFORM] Hash join on int takes 8..114 seconds

2008-11-19 Thread PFC
Query below seems to use indexes everywhere in most optimal way. dokumnr column is of type int Speed of this query varies rapidly: In live db fastest response I have got is 8 seconds. Re-running same query after 10 seconds may take 60 seconds. Re-running it again after 10 seconds may take 114

Re: [PERFORM] Very Urgent : Sequences Problem

2008-11-19 Thread Greg Smith
On Wed, 19 Nov 2008, Josh Berkus wrote: Cross-posting two PostgreSQL mailing lists for a problem which is very urgent to you, but not to us, is a guarenteed way not to get a useful answer. Posting to the performance list like this, with a question that in no way whatsoever has anything to do