Awesome! :)
On 2017.04.21. 1:30, Adriano dos Santos Fernandes wrote:
> Em 20/04/2017 17:53, Vlad Khorsun escreveu:
>> Also it is necessary
>> to teach engine to use that metadata (instead of current one) within
>> attachment
>> working "in the past".
>>
> I'm doing a prototype implementation of
Em 20/04/2017 17:53, Vlad Khorsun escreveu:
> Also it is necessary
> to teach engine to use that metadata (instead of current one) within
> attachment
> working "in the past".
>
I'm doing a prototype implementation of this for active transactions,
i.e., the things I mentioned in this thread
20.04.2017 10:12, Molnár Attila wrote:
> +1 for this feature. I would be very happy for this. Also it would be
> awesmone if this consistent view were accessible later in time (this
> woudl mean garbage collection blocking).
Blocking of GC is the easiest part of this task. One need also to
20.04.2017 17:50, Dimitry Sibiryakov wrote:
> 20.04.2017 16:20, Vlad Khorsun wrote:
>>> even in the simplest cases like "select f from t1 union select f from t2"?
>> This case nor simplest nor better for parallel execution than "ordinary"
>> "select * from t".
>
> Union used to produce
20.04.2017 16:20, Vlad Khorsun wrote:
>> even in the simplest cases like "select f from t1 union select f from t2"?
>This case nor simplest nor better for parallel execution than "ordinary"
> "select * from t".
Union used to produce plan SORT (T1 NATURAL), SORT(T2 NATURAL). Both record
20.04.2017 15:49, Leyne, Sean wrote:
> "select f from t1 union select f from t2" is ONE statement with 2 parts!
>
> "Attachment" refers to the connection between a client and the server, it
> does not imply anything about how the engine might decompose a statement or
> how the parts could/would
20.04.2017 13:04, Dimitry Sibiryakov wrote:
> 19.04.2017 14:12, Vlad Khorsun wrote:
>> Engine can't run more than one statement in attachment at same time.
>> This will not be
>> changed.
>
> Does it also mean that Firebird will never be able to execute parts of
> single query in
>
> Being able to start next transaction,
> basically, from the point where the previous left would be so convenient and
> remove a lot of hacks we have in place right now.
To be clear, in my example/use case the "master transaction" would still be
active and the related connection would be
19.04.2017 14:12, Vlad Khorsun wrote:
>Engine can't run more than one statement in attachment at same time. This
> will not be
> changed.
Does it also mean that Firebird will never be able to execute parts of
single query in
parallel even in the simplest cases like "select f from t1
>This statement i not understand. Do you speak about transaction ? Or
>about
Transaction.
> statement\cursor ? If later, why do you can't remember id of last fetched
> row
> and start next fetch from this position ?
That's what we do now, in a nutshell. The problem is of course to have
>Did you consider export of the data to local files and then sending of
>these files?
We did. And discarded it because of the hassle of managing these files.
> File transfer over Internet is much faster.
I'm not uploading over FIrebird's protocol. It's pushed over custom
HTTPs
20.04.2017 9:36, Jiří Činčura wrote:
>> Could you explain, please ?
>
> Sure. There's a part of our system that reads data and sends these over
> the internet. Given the deployments on the customer side the internet is
> often very very slow (<100kBps sometimes), so we decided to not keep
>
20.04.2017 8:36, Jiří Činčura wrote:
> Sure. There's a part of our system that reads data and sends these over
> the internet. Given the deployments on the customer side the internet is
> often very very slow (<100kBps sometimes), so we decided to not keep
> transaction open, but do it repeatedly
19.04.2017 23:27, Leyne, Sean wrote:
> I never said anything about a single application!
>
> I mentioned in one of my posts that the Master connection would request a
> "Transaction Clone" which would be a GUID that could be sent to another
> *process* to allow that process' connection to link
+1 for this feature. I would be very happy for this. Also it would be
awesmone if this consistent view were accessible later in time (this
woudl mean garbage collection blocking).
On 2017.04.18. 20:56, Leyne, Sean wrote:
>
>> If you need simultaneous queries - make them possible,
>> what the
>Could you explain, please ?
Sure. There's a part of our system that reads data and sends these over
the internet. Given the deployments on the customer side the internet is
often very very slow (<100kBps sometimes), so we decided to not keep
transaction open, but do it repeatedly in bacches
16 matches
Mail list logo
