airly slow. (significantly slower
> than 6.4/7.0)
>
Is the comparison for the < 8k data ?
Is it as fast as 6.4/7.0 except concurrent write ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unre
ettup and
> heap_fetch:
>
SELECT seems to be able to return a different result
from that of preceding SELECT FOR UPDATE even after
applying your change.
SELECT doesn't seem guilty but the result is far
from intuitive.
It seems impossoble for all queires inside such
a function to use a
ssible in 7.1?
> >
> >Just looked in heapam.c - I can fix it in two hours.
> >The question is - should we do this now?
> >Comments?
>
> It's a bug; how confident are you of the fix?
>
I doubt if it's a bug of SELECT. Well what
'concurrent UPDATE the
e latest tuples. I don't think of any simple
way for 'SELECT FOR UPDATE' to have the same visibility as
simple SELECT.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
x27;
Seems a chained query is issued.
Queries in a chained query are parse and analyzed all
together before the chained query's execution. Therefore
SELECT couldn't see tables which didn't exist before
the execution.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
gt; session1<< select id from idseq where name = $1::text;
Queries in a function are executed under the
snapshot of the top level query.
So SELECT could never see changes made by
other backends once the top level query
started. If you change the definition of above
function to return setof int8,you may see 2
rows returned.
Maybe you could add 'for update' clause to your
above query.
> session1<< ' language 'sql';
> session1>> CREATE
>
Regards.
Hiroshi Inoue
But, supose I make a query
> select * from table where code > 'AAA' limit 10. it will read the entire
> table only to give me the first 10 while in release 6.5 it will fetch the
> index for the first 10 in a very fast manner, indeed the 6.5 release
> resolves in 1 second while the 7.0 release resolves in 10-20 sec.
>
Probably the distribution of rows in teste where login > 'AAA' isn't
uniform. You had better add 'ORDER BY login' to your query.
Regards.
Hiroshi Inoue
> -Original Message-
> From: Tom Lane
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Hmm,Andreas's original function seems to contain other statements.
> > If the function contains DML statements for the table Temp_Num_Table,
> > it
7;round to writing querytree copy routines
> for them. Ian Turner finally did all the gruntwork for that a few
> weeks ago, so this does work in current sources and will be in 7.1.
>
Hmm,Andreas's original function seems to contain other statements.
If the function contains DML statements for the table Temp_Num_Table,
it wouldn't work properly. i.e 1st call would work but 2nd call woudn't.
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
XREF,above condition
isn't satisfied any longer. So isn't the constraint for the table XREF
either ?
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
x27;t understand very well how
> these are used. Maybe someone else can say or you can experiment...
>
AFAIK,there's no pseudo-column like Oracle's rownum which is
dynamically allocated at execution time.
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
ere seems to be more serious problems.
1) The constraint is not only for the defined table but also for referenced
tables in the subquery.
2) There should be some standard lock mechanism for the range restricted
by the subquery.
I'm suspicious that we should/could implement constra
unction out of VACUUM and making it invokable as a separate
> > statement.
>
> Added:
>
> * Remove ANALYZE from VACUUM so it can be run separately without locks
> * Gather more accurate statistics using indexes
>
Gathering statistics using indexes on-fly is best.
However
example,from 0.5 to 0.2 which is the fudge factor of attdisbursion
calculation.
Regards.
Hiroshi Inoue
[EMAIL PROTECTED]
14 matches
Mail list logo
