Blagoj Petrushev wrote
> I know for example that redis has this feature, the EXPIRE / EXPIREAT
> / TTL commands.
> http://redis.io/commands/expire
Redis seems to have decided that limiting the extent to which EXPIRE works
is necessary in order to maintain performance; I'd be very worried about a
similar situation here - in addition to solving the master-slave replication
issue.
One random thought I had would that this would make an excellent addition
for an UNLOGGED table; if even just for an initial implementation phase. It
would seem that both features would share similar use cases and the main
current limitation of UNLOGGED tables is the same one that make implementing
EXPIRE difficult - replication - and eating some of the savings from not
WAL-logging would still result is reasonably good performance; as long as
only UNLOGGED tables are impacted.
One question is how much actual speed benefit can be had by implementing
this in core instead of advising users to put an "expires_at" field on those
tables that need them and to make sure usage of the table involves limiting
that field to "<= now()"? If it would be possible to only look for the
field on tables defined to have it, and not all tables, this becomes less of
an issue and the advantage of having it built-in when used becomes dominate
- though someone would still need to code it; which doesn't seem trivial for
normal tables; and the option of an explicitly user-managed interface seems
quite viable.
David J.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/EXPIRE-as-a-statement-tp5802378p5802386.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.