Re: Surjective functional indexes

From: "Sven R(dot) Kunze" <srkunze(at)mail(dot)de>
To: Christoph Berg <myon(at)debian(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Surjective functional indexes
Date: 2017-05-29 19:25:00
Message-ID: f1c0363b-eddd-ca1d-9def-e0b81f23bd63@mail.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29.05.2017 19:21, Christoph Berg wrote:
> I think the term you were looking for is "projection".
> https://en.wikipedia.org/wiki/Projection_(set_theory)

Maybe, I am seeing too much of a connection here but recently Raymond
Hettinger held a very interesting talk [1] at PyCon 2017.

For those without the time or bandwidth to watch: it describes the
history of the modern dict in Python in several steps.

1) avoiding having a database scheme with columns and rows and indexes
2) introducing hashing with bucket lists
3...6) several improvements
7) in the end looks like a database table with indexes again ;)

If you have the time, just go ahead and watch the 30 min video. He can
explain things definitely better than me.

In order to draw the line back on-topic, if I am not completely
mistaken, his talks basically shows that over time even datastructures
with different APIs such as dicts (hashes, maps, sets, etc.) internally
converge towards a relational-database-y design because of performance
and resources reasons.

Thus let me think that also in the on-topic case, we might best be
supporting the much narrow use-case of "Projection" (a term also used in
relation database theory btw. ;-) ) instead of non-surjective functions.

Cheers,
Sven

[1] https://www.youtube.com/watch?v=npw4s1QTmPg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-05-29 19:25:35 Re: logical replication busy-waiting on a lock
Previous Message Andres Freund 2017-05-29 19:24:43 Re: Use of non-restart-safe storage by temp_tablespaces