Re: Super PathKeys (Allowing sort order through precision loss functions)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Super PathKeys (Allowing sort order through precision loss functions)
Date: 2018-10-30 19:52:05
Message-ID: 13153.1540929125@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> I've started working on something I've ended up calling "Super
> PathKeys". The idea here is to increase the likelihood of a Path with
> PathKeys being used for a purpose that requires a less strict sort
> order due to ordering being required from the return value of some
> precision loss function.

I'm a little confused by the terminology here, or why this has anything
at all to do with a new sort of pathkey. It seems like the idea you're
driving at is to be able to mark a function as being order-preserving,
in the sense that if one input is known sorted then the output will
also be sorted (by the same or a related opclass). You probably need
some additional constraints, like any other inputs being constants,
before that really works. But given that, I don't see why you need a
new kind of pathkey: you just have a new way to conclude that some
path is sorted by the pathkey you already want.

Maybe if I read the patch it'd be clearer why you want to describe it
that way, but I'm too lazy to do that right now. One thing I would
say though is that a pg_proc column identifying the interesting input
parameter is insufficient; you'd need to *explicitly* say which opclass(es)
the sorting behavior guarantee applies for.

> -- Test a more complex case where the superkey can be matched to
> multiple pathkeys
> explain (costs off) select date_trunc('year', ts), date_trunc('month',
> ts), a, count(*) from tstbl group by 1,2,3 order by 1,2,3;
> QUERY PLAN
> -----------------------------------------------------------------------------
> GroupAggregate
> Group Key: date_trunc('year'::text, ts), date_trunc('month'::text, ts), a
> -> Index Only Scan using tstbl_ts_a_idx on tstbl
> (3 rows)

[ squint... ] Does that really work? If so, how? It would need a whole
lot more knowledge about the behavior of date_trunc than I think could
possibly be reasonable to encode in a general mechanism.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sehrope Sarkuni 2018-10-30 20:21:02 Re: Sequential UUID Generation
Previous Message Andres Freund 2018-10-30 19:37:20 Re: Lambda expressions (was Re: BUG #15471)