23.11.2016 9:06, Norbert Saint Georges n...@tetrasys.eu [firebird-support]
wrote:
> For tables of several hundred millions of recordings, if we organize
> the first eight bytes in a less cahotic way, this will lighten Firebird
> by making it faster?
Yes, that's why sequential GUID was
22.11.2016 21:01, 'Leyne, Sean' s...@broadviewsoftware.com [firebird-support]
wrote:
>> There would be a lot of advantage, for Firebird, in using this kind of guid?
>
> Yes, Firebird indexes use prefix compression so the leading 14 chars of the
> above values
> would be stored under a single
> > @Ann
> > I will run some test and see what happens if the guids are generated
> > in way where the last part varies. Like this:
> > 39db9ec6-178e-77b4-5d7b-d4e969b0cd98
> > 39db9ec6-178e-e4ba-54ed-92347a131663
> > 39db9ec6-178e-c95b-c709-a42e349410df
>
> There would be a lot of advantage, for
On Nov 22, 2016, at 6:56 AM, kragh.tho...@yahoo.com [firebird-support]
wrote:
>
> Pagesize is 16384 and pagebuffers is 256. Servermode is superclassic.
> If I drop the primary key/index everything works as expected.
>
Interesting. GUIDs produce really fat
Hi,
i agree with you
i suppose that time spend by GC should be measured and if it take to much time
then stop GC and try again leter.
E.g. when i do delete from milions_table
and then do SELECT COUNT(*) form milions_table
it should not clear whole garbages and stop query until GC finished.
---In firebird-support@yahoogroups.com, wrote :
>> Here you delete some records, but then count whole table.
>>Add same "where" condition as in "count" query
>
> I think the execution of select count is for garbage collection.
Sure
> If count of records that does not exists is
>
> Here you delete some records, but then count whole table.
> Add same "where" condition as in "count" query
>
> Regards,
> Vlad
I think the execution of select count is for garbage collection.
If count of records that does not exists is executed, will be the garbage
collection executed for