On 26.02.2015 13:48, Thomas Kellerer wrote:
Sven R. Kunze schrieb am 26.02.2015 um 13:23:
If you think Reverse Key Indexes have no usage here in PostgreSQL, you should
not support convenience features
for easily improving performance without breaking the querying API
Sorry for my bad English:
Sven R. Kunze schrieb am 26.02.2015 um 13:23:
> If you think Reverse Key Indexes have no usage here in PostgreSQL, you should
> not support convenience features
> for easily improving performance without breaking the querying API
It's also unclear to me which "performance" you are referring to.
On 02/26/2015 12:31 AM, Josh Berkus wrote:
On 02/14/2015 10:35 AM, Sven R. Kunze wrote:
Thanks for the immediate reply.
I understand the use case is quite limited.
On the other hand, I see potential when it comes to applications which
use PostgreSQL. There, programmers would have to change a l
On 26.02.2015 12:45, Thomas Kellerer wrote:
Sven R. Kunze schrieb am 26.02.2015 um 12:04:
I just thought about btree indexes here mainly because they well-known and
well-used in ORM frameworks.
If your ORM framework needs to know about the internals of an index definition
or even requires a c
Sven R. Kunze schrieb am 26.02.2015 um 12:04:
> I just thought about btree indexes here mainly because they well-known and
> well-used in ORM frameworks.
If your ORM framework needs to know about the internals of an index definition
or even requires a certain index type, then you should ditch t
On 25.02.2015 23:31, Josh Berkus wrote:
On 02/14/2015 10:35 AM, Sven R. Kunze wrote:
Thanks for the immediate reply.
I understand the use case is quite limited.
On the other hand, I see potential when it comes to applications which
use PostgreSQL. There, programmers would have to change a lot
