Dear vlad,
yes the prepared statement pooling is working like a charm ! the perf of the
database are huge now !
but the problem is that i can not do pooling of prepared statement for UPDATE
(can not let the connection open) :(
OK, thanks...
so it's confirm :
1/ try to avoid table with big number of fields (mostly try to make the size of
a record (size used by all fields) more little as possible)
2/ try to use a pool of parametized statement (read only read commited)...
because here it's only the prepare that is
--- In firebird-support@yahoogroups.com, nathanelrick wrote:
OK, thanks...
so it's confirm :
1/ try to avoid table with big number of fields (mostly try to make the size
of a record (size used by all fields) more little as possible)
Nope. It is the same as if you going to avoid tables
We hope that whole statistics subsystem will be reworked in v3.
from http://www.firebirdsql.org/en/server/
We expect to see Alpha 1 released in Q1 2012
is it still true ?
Many of the great achievements of the world were accomplished by tired and
discouraged men who kept on working
Hi,
you compare aples with oranges ..
look at your test - and not index read but pages read
then you will see where is differece
i see here only disc operation speed
and you do test with random data - try use the same ids in all tests
becaouse you can use random id but on the asme database
i Understand now ! it's was the fault of yahoo that automatiquely add the old
messages history ... i will now delete this history before to post ... thanks
On Fri, 09 Mar 2012 10:37:39 -, nathanelrick nathanelr...@yahoo.fr
wrote:
i Understand now ! it's was the fault of yahoo that automatiquely add
the
old messages history ... i will now delete this history before to post
...
thanks
You could also subscribe to the mailinglist and use that
Hi Rick,
thanks Karol, but here the probleme seem to be in the prepare ... and the
stat don't show us how many page fetch/read etc.. :(
I think the main problem in your case is that you only got answers on
snippets of information you gave in this list. You blame Firebird and it's
architecture
In one of your mails you wrote you use a transaction pool. I personally do
not understand the use of that, since transactions with Firebird should be
as short as possible. If you keep transactions open for a long time,
performance can degrade over time with increasing users and load because
no no, i don't blame firebird at all ! (sorry for the !)
In one of your mails you wrote you use a transaction pool. I personally do
not understand the use of that, since transactions with Firebird should be
as short as possible. If you keep transactions open for a long time,
performance
3/ as i know readonly can stay open undefinitively without hurting the
database
Provided the isolation level also is READ COMMITTED. If you use SNAPSHOT as
your isolation level, then even read-only transactions block garbage collection
(at least, I cannot imagine how to keep a stable view of
Hi All,
Been watching recently and decided to have a quick gander hoping to
reproduce the OPs original issues with slower selects from a table
containing a varchar(1) versus a table containing no varchar(1)
field.
Test rig:
Centos 5.3 32 bit
Firebird 2.5.0 Classic Server 32 bit
On Fri, Mar 9, 2012 at 8:35 AM, nathanelrick nathanelr...@yahoo.fr wrote:
In one of your mails you wrote you use a transaction pool. I personally
do
not understand the use of that, since transactions with Firebird should
be
as short as possible. If you keep transactions open for a long
Thanks for your study that show the problem i try to point !
I can only image that the unrelated contents of a table somehow impact on
the performance of an index - no idea why.
yes, and worse, with blob instead of varchar it's the same ... but i always
learn than blod are store outside the
always good to read after you :)
--- In firebird-support@yahoogroups.com, David Hollings wrote:
...
Conclusion:
Baffled why a select (which could never possibly return a result) reads
~1150 pages from DESC_VARCHAR but only ~230 pages from DESC_EMPTY given that
the two indices on IDOBJ columns are virtually identical
In all three cases you are 50ms, so what's the problem? Your niggles
are in the millisecond area right now. ;-)
oupps, but 50 ms it's ok when you do time to time, but when you have 50 client
(and that not too much for a web service) doing this at the same time then the
50 ms become 0.5
In all three cases you are 50ms, so what's the problem? Your niggles
are in the millisecond area right now. ;-)
oupps, but 50 ms it's ok when you do time to time, but when you have 50
client (and that not too much for a web service) doing this at the same time
then the 50 ms become 0.5
nathanelrick [2012-03-08 08:59] :
I agree, what will be good is to have something like a hotline support
service ... if someone have some offer i will be happy to receive it
IBPhoenix provide this
http://www.ibphoenix.com/services
In the prepare step, roughly explained, the engine parses the SQL text,
checks the syntax and compiles it into a Firebird native executable form
(BLR).
Yes this what i understand too, and this why 50 ms seem huge ...
My guess is that you are assigning the SQL text over and over again,
In the prepare step, roughly explained, the engine parses the SQL text,
checks the syntax and compiles it into a Firebird native executable form
(BLR).
Yes this what i understand too, and this why 50 ms seem huge ...
My guess is that you are assigning the SQL text over and over again,
C'mon. This ain't bad. *g* Ever tried to do the same with the big guns
Oracle, MSSQL etc.?
big gum? but Firebird is not a nuclear weapon compare to them ? :)
I'm afraid, this is only possible (if at all), if your middle-tier is
somehow caching prepared statements/objects available for
yes, i know how to do a pool of statement, i thing i will do it easily ...
but now the question is it normal that a PREPARE use so much of time ? is
it not look like a conception error in the engine ?
Can you please stop top-posting, because this removes the context of
your reply. Or do you
Can you please stop top-posting, because this removes the context of
your reply. Or do you read a book from the end to the beginning? ;-)
sorry i not understand ? i simply in yahoo.com go to the message and click
reply to the message that all ? what i do wrong ? what is top-posting ?
nathanelrick wrote:
Can you please stop top-posting, because this removes the context of
your reply. Or do you read a book from the end to the beginning?;-)
sorry i not understand ? i simply in yahoo.com go to the message and click
reply to the message that all ? what i do wrong ? what is
Top posting is when your reply is above the quoted message you are
replying to. This message from me uses top posting. In your message in
response to Thomas, which is quoted below, you used bottom posting.
Bottom posting is strongly preferred by many people because it is more
organized to add your
Thanks Svein,
Is your query,
select IDObj From DESCRIPTION where ID='ID_HAS_NEVER_EXISTED', or
select IDObj From DESCRIPTION where
ID='ID_THAT_IS_RECENTLY_DELETED_UPDATED_OR_ADDED'?
First case ID='ID_HAS_NEVER_EXISTED', so unfortunatly it's not this ..
also i do the test on a fresh
THE DDL of the 3 sample table :
CREATE TABLE DESC_VARCHAR (
IDOBJ VARCHAR(20),
COMMENT VARCHAR(1)
);
CREATE INDEX DESC_VARCHAR_IDX ON DESC_VARCHAR(IDOBJ);
CREATE TABLE DESC_BLOB (
IDOBJ VARCHAR(20)
COMMENT BLOB
);
CREATE INDEX DESC_BLOB_IDX ON DESC_BLOB(IDOBJ);
nathanelrick [2012-03-07 13:33] :
if you understand something . moving the page size from 8 to 16 reduce by
10 the speed of the 2 first query, but still 10x more slower than the last
variante
obviously there are less data pages to read for the third table
see gsat -d result for these
THE DDL of the 3 sample table :
CREATE TABLE DESC_VARCHAR (
IDOBJ VARCHAR(20),
COMMENT VARCHAR(1)
);
CREATE INDEX DESC_VARCHAR_IDX ON DESC_VARCHAR(IDOBJ);
CREATE TABLE DESC_BLOB (
IDOBJ VARCHAR(20)
COMMENT BLOB
);
CREATE INDEX DESC_BLOB_IDX ON
On Wed, Mar 7, 2012 at 1:25 AM, nathanelrick nathanelr...@yahoo.fr wrote:
yes Rick, but what will be my job after :( i will be fired because i will
become useless :(
but what the specialist will say me here ? yes it's a true disaster, the
index entries are spawn in the record page, mean that
OK, thank i see now exactly where is the probleme is
it's in the PREPARE step
select IDObj From desc_varchar where IDObj='NOT_EXIST';
PREPARE_STATEMENT: 40 ms
EXECUTE_STATEMENT_FINISH: 0 records fetched
0 ms, 4 read(s), 4 fetch(es)
select IDObj From desc_blob where
You've presented the list with a problem that we haven't been able to solve
given the information available. And no, the index entries are NOT spawn
in the record page - index entries use only the key values, they're stored
on index pages, and they're prefix compressed. I haven't a clue what
no one have any explanation ?
what i don't understand is that in select IDObj From DESCRIPTION where
ID='ID_NOT_EXIST' the speed is slow when no record are founded (so the number
of field/size in table Description must not matter, only the size of the index)
! but it's not the case, i do
OK, doing more test, i pass the Page size to 16K (instead of 8k before) and now
CREATE TABLE DESCRIPTIONS
(
IDObj VARCHAR(15) NOT NULL,
type SMALLINT NOT NULL,
Lang VARCHAR(3) NOT NULL,
Descr VARCHAR(1),
PRIMARY KEY (IDObj, type, Lang)
);
and a foreign key on IDOBJ
with 32
What is this index depth (check with gstat) when you have 8K page and
16k?
Carlos
Firebird Performance in Detail - http://videos.firebirddevelopersday.com
www.firebirdnews.org - www.FireBase.com.br
n OK, doing more test, i pass the Page size to 16K (instead of 8k before) and
now
n CREATE TABLE
On Thu, 01 Mar 2012 12:38:15 -, nathanelrick nathanelr...@yahoo.fr
wrote:
OK, doing more test, i pass the Page size to 16K (instead of 8k before)
and now
CREATE TABLE DESCRIPTIONS
(
IDObj VARCHAR(15) NOT NULL,
type SMALLINT NOT NULL,
Lang VARCHAR(3) NOT NULL,
Descr
Dear Mark,
Quite simple: with a field of VARCHAR(1) on 8K pages it needs to read
at least two pages if the VARCHAR is filled for over 80%, for smaller
VARCHARs there is still a relatively high chance it will need to read 2
pages. For page sizes of 16K this is less, but still relatively
hello,
i do some more tests to investigate ...
* When the table is read only by a single user (or very few user) speed is fast
(around 30 ms by select)
* when the table is read by more users (around 50), then the speed go down !
around 500 ms by select
* When the table is also updated by
no idea ? do you thing it's could be a bug in firebird (2.5) ? 1 second to
retrieve on record by his primary index seam very much too long :( and even if
their is no record founded it's take 1 second to return :(
--- In firebird-support@yahoogroups.com, nathanelrick nathanelrick@...
wrote:
41 matches
Mail list logo
