10.05.2014 9:03, Molnár Attila wrote:
*VARIANT data type in PSQL*
- gain : a little memory and/or CPU overhead but much cleaner code. Also
rdb$get/set_context value colud be variant.
Welcome to the hell of unpredictable type conversion.
*Optimization II.
*- temporal indexing of
I will see if I can come up with a solution for Firebird 3 without needing
RDB$TRANSACTIONS to be unprotected, but doesn't - potentially - degenerate
to iterating over a list of thousands if not millions of transaction
records when recovering a distributed transaction.
Am i already told
On 2014.05.10. 9:52, Dimitry Sibiryakov wrote:
10.05.2014 9:03, Molnár Attila wrote:
*VARIANT data type in PSQL*
- gain : a little memory and/or CPU overhead but much cleaner code.
Also
rdb$get/set_context value colud be variant.
Welcome to the hell of unpredictable type
10.05.2014 10:12, Molnár Attila wrote:
OK, this just means smaller treshold rate. But with this some case you
can gain HUGE performance boost (especially when the resultset can't fit
into memory and have to write to disk)
Big result set is a sign of wrong application design. And in any case
Derived table usage for this problem is GREAT idea! Why the ... I didn't
tought that!
Thank you!
On 2014.05.10. 10:26, Dimitry Sibiryakov wrote:
10.05.2014 10:12, Molnár Attila wrote:
OK, this just means smaller treshold rate. But with this some case you
can gain HUGE performance boost
On Sat, 10 May 2014 10:53:05 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
I will see if I can come up with a solution for Firebird 3 without
needing
RDB$TRANSACTIONS to be unprotected, but doesn't - potentially -
degenerate
to iterating over a list of thousands if not millions of
On Sat, 10 May 2014 13:46:46 +0300, Vlad Khorsun
hv...@users.sourceforge.net wrote:
Surprise : after you got list of tx numbers it can be used to query
RDB$TRANSACTIONS for additional info.
But then I could just as well query RDB$TRANSACTIONS directly. I don't
know the Firebird
On 5/2/2014 3:25 PM, Vlad Khorsun wrote:
OK, the alternative to record lookups is to store the transaction id in
index. This would require an index insertion for all indexes defined on
a table even if the key value didn't change. It would also require a
corresponding index deletion for each
On Sat, 10 May 2014 13:46:46 +0300, Vlad Khorsun wrote:
Surprise : after you got list of tx numbers it can be used to query
RDB$TRANSACTIONS for additional info.
But then I could just as well query RDB$TRANSACTIONS directly. I don't
know the Firebird transaction id: I need to identify
After thinking more on it...
I could (with FB 2.5 and later) also query with
RDB$TRANSACTION_DESCRIPTION = X'' (where X'' is the serialized Xid
I am looking for) although I wonder about its performance implications. On
the other hand, recovery situations should be rare so it might
10.05.2014 14:03, Vlad Khorsun wrote:
For blob's we still need that lists, yes
No. In my workcopy I got rid of them for blobs. The trick is not to garbage
collect
blobs that are referenced by potentially active versions in undo log.
--
WBR, SD.
Claudio Valderrama C. cva...@usa.net писал(а) в своём письме Wed, 07 May
2014 13:00:43 +0400:
-Original Message-
From: Philippe Makowski [mailto:pmakow...@ibphoenix.fr]
Sent: Miércoles, 07 de Mayo de 2014 3:05
Hi,
just for information, seems that some last commit broke
something
10.05.2014 14:50, Vlad Khorsun wrote:
Explain, please, because i see no way to use undo log (which is
maintained in
memory for *currently* active tx) for garbage collection of record chain
which primary
version was created by *another* tx.
It is not needed because blob id is a
In short: blob id which going version is referring to can cleaned only if
it is not
referred by both previous or next versions. All other versions are irrelevant
because they
cannot refer the same blob id. At least in current codebase which creates a
new copy of
blob content on
10.05.2014 15:30, Vlad Khorsun wrote:
Here you wrong: if blob contents was not changed by update, there will
be no new blob.
Yes, and in this case blob cannot be garbage collected because next record
version
refers to it. No need to analyze whole versions chain (collect staying list)
10.05.2014 15:30, Vlad Khorsun wrote:
if blob contents was not changed by update, there will be no new blob.
Imagine that we have version chain like this (only blob ids are listed):
1-2-2-3-3-3(first staying)-3-4-5-5
Because to the right from first staying version cannot be any blob id
On 10-05-2014 04:03, Molnár Attila wrote:
*VARIANT data type in PSQL*
This would be very easy to implement (variables only). What would be the
use cases?
Adriano
--
Is your legacy SCM system holding you back? Join
On 5/10/2014 10:43 AM, Adriano dos Santos Fernandes wrote:
On 10-05-2014 04:03, Molnár Attila wrote:
*VARIANT data type in PSQL*
This would be very easy to implement (variables only). What would be the
use cases?
Any place you need a variable.
I would argue against an explicit VARIANT type,
On Sat, May 10, 2014 at 3:03 AM, Molnár Attila amol...@mve.hu wrote:
*Optimization II. *- temporal indexing of materialization : e.g. when
ORDER/GROUP BY has no index then currently the whole resultset is
materialized, and the sorting moves the whole row each time. Instead of
this it
10.05.2014 15:30, Vlad Khorsun wrote:
Here you wrong: if blob contents was not changed by update, there will
be no new blob.
Yes, and in this case blob cannot be garbage collected because next record
version
refers to it. No need to analyze whole versions chain (collect staying
Thank you Claudio. Build 3.0.0.31129 works without errors.
Unfortunately the problem with the system tables still have
Use CONNECT or CREATE DATABASE to specify a database
SQL connect 'localhost:test' user 'sysdba' password 'masterkey';
Database: 'localhost:test', User: sysdba
SQL show
21 matches
Mail list logo
