From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jordan Savoca To: location@lists.ipfire.org Subject: Re: Auto-generated plaintext updates; re: regression Date: Thu, 10 Mar 2022 16:02:03 +0000 Message-ID: In-Reply-To: <7433146A-A01A-49CE-A54C-AE5E33372D12@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3311593145906966331==" List-Id: --===============3311593145906966331== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 3/10/22 07:48, Michael Tremer wrote: > I would strongly recommend this, because parsing the text database and goin= g with the first match is quite likely going to give you inaccurate results. >=20 > The reason why we are going with a binary format is because it is organised= as a binary tree and therefore can be searched *very* quickly. It also allow= s us to store multiple networks with the same start address, but a different = prefix length which is what you won=E2=80=99t have in a relational database a= nd therefore you will quite likely have inaccurate results. Yes! I store block announcements w/ autonomous system table foreign keys=20 to support anycast networks and varied prefixes without relation to or=20 dependence on the order in which the set is parsed, albeit at a=20 performance cost as you suggested. > We kept the library as small as possible and we are looking at upstreaming = it to all major distributions because that will help integrating it into othe= r software a lot easier. Any help with this would be greatly appreciated. Very cool, that would be sweet. --=20 Jordan Savoca --===============3311593145906966331==--