Craig James <[EMAIL PROTECTED]> writes:
> The two queries below produce different plans.
> select r.version_id, r.row_num, m.molkeys from my_rownum r
> join my_molkeys m on (r.version_id = m.version_id)
> where r.version_id >= 320
> and r.version_id < 330
> order by r.version_id;
> sel
Sorry, I forgot to mention: This is 8.1.4, with a fairly ordinary configuration
on a 4 GB system.
Craig
Craig James wrote:
The two queries below produce different plans.
select r.version_id, r.row_num, m.molkeys from my_rownum r
join my_molkeys m on (r.version_id = m.version_id)
where r.vers
The two queries below produce different plans.
select r.version_id, r.row_num, m.molkeys from my_rownum r
join my_molkeys m on (r.version_id = m.version_id)
where r.version_id >= 320
and r.version_id < 330
order by r.version_id;
select r.version_id, r.row_num, m.molkeys from my_rownu
"Marc Mamin" <[EMAIL PROTECTED]> writes:
> Can I optimize this function with:
> a) remove the EXCEPTION clause (Is there an underlying lock that prevent
> concurrent inserts ?)
No.
> b) declare the function being IMMUTABLE ?
Certainly not --- it's got side-effects.
rega
Hello,
I have a simple table id/value, and a function that returns the id of a
given value, inserting the later if not yet present. The probability
that a value already exist within the reference table is very high.
Different db users may have their own reference table with different
content, bu
Hi List,
Is there anyway so as to indicate the Query Analyser not to use the
plan which it is using regularly, and use a new plan ?
From where do the Query Analyser gets the all info to prepare a plan?
Is it only from the pg_statistics table or are there anyother tables
which have this info. s
Yes, I tried all WAL sync methods, but there was no difference...
However, there was a huge difference when I run the same tests under
Solaris10 - 'fdatasync' option gave the best performance level. On the
same time direct I/O did not make difference on Solaris 10 :)
So the main rule - there is n
Hi,
I think this result will be useful for performance discussions of
postgresql against other databases.
http://www.spec.org/jAppServer2004/results/res2007q3/
More on Josh Berkus's blog:
http://blogs.ittoolbox.com/database/soup/archives/postgresql-
publishes-first-real-benchmark-17470
