s
(6 rows)
Boom. This is actually usefull.
It does take 70 seconds for the biggst network though. The index is also
rather large:
public | routes_cidr_to_range_idx | index | htj | routes | 158 MB |
Table is 119MB data. The gist index was 99 MB.
Best regards, Henrik
Henrik Th
e)
Some observations:
- v6 is faster than v4 which is expected.
- The slowest prefixes by all seem to start bits '11'.
However it is only by a factor of 1.5x which is not really significant
Best regards, Henrik
Henrik Thostrup Jensen
Software Developer, NORDUnet
--
S
[.] inet_gist_decompress
1.09% postgres [.] 0x000c067e
1.03% postgres [.] 0x000c047e
0.77% postgres [.] 0x002f0e57
0.75% postgres [.] gistcheckpage
This seemed to stay reletiv
On Wed, 26 Aug 2015, Emre Hasegeli wrote:
Are the coverage operatons just that expensive?
They shouldn't be. A similar query like yours works in 0.5 second on my laptop:
[snip]
I get the same from your testcase.
Maybe, something we haven't expected about your dataset causes a
performance
On Wed, 26 Aug 2015, Henrik Thostrup Jensen wrote:
Can you try 9.5 to see if they help?
I'll try installing it and report back.
I upgraded to 9.5 (easier than expected) and ran vacuum analyze.
The query planner now chooses index scan for outer and inner join. This
seems to cut off ro
return some constants, so it is expected. We
developed better ones for 9.5. PostgreSQL 9.5 also supports index
only scans with GiST which can be even better than plain index scan.
OK, that is interesting.
Can you try 9.5 to see if they help?
I'll try installing it and report back.
Hi
I'm trying to get a query to run fast enough for interactive use. I've gotten
some speed-up, but still not there. It is for a tool called IRRExplorer
(http://irrexplorer.nlnog.net/) that correlates IP routes between Internet
Route Registries and real-world routing information. We landed on Pos
