From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)compiler(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Do we want a hashset type? |
Date: | 2023-06-07 17:37:45 |
Message-ID: | 86073c90-062b-a52a-25cd-fcc3f7a30ed4@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/7/23 16:21, Joel Jacobson wrote:
> On Tue, Jun 6, 2023, at 13:20, Tomas Vondra wrote:
>> it cuts the timing to about 50% on my laptop, so maybe it'll be ~300ms
>> on your system. There's a bunch of opportunities for more improvements,
>> as the hash table implementation is pretty naive/silly, the on-disk
>> format is wasteful and so on.
>>
>> But before spending more time on that, it'd be interesting to know what
>> would be a competitive timing. I mean, what would be "good enough"? What
>> timings are achievable with graph databases?
>
> Your hashset is now almost exactly as fast as the corresponding roaringbitmap query, +/- 1 ms on my machine.
>
Interesting, considering how dumb the the hash table implementation is.
> I tested Neo4j and the results are surprising; it appears to be significantly *slower*.
> However, I've probably misunderstood something, maybe I need to add some index or something.
> Even so, it's interesting it's apparently not fast "by default".
>
No idea how to fix that, but it's rather suspicious.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2023-06-07 18:50:30 | Re: is pg_log_standby_snapshot() really needed? |
Previous Message | Joseph Koshakow | 2023-06-07 17:33:03 | Re: is_superuser is not documented |