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
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
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
> 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
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
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
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
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
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
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
Віталій Тимчишин 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
Something weird with your example which doesn't have the same result, see
row count with explain analyze:
cruz=# SELECT version();
version
-
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
13 matches
Mail list logo
