On 26.02.2015 13:37, Heikki Linnakangas wrote:
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 Postgre
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
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 of code to
> tweak existing (an
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 of code to
tweak existing (and more importantly working) queries to hash/reverse an
"Sven R. Kunze" writes:
> does PostgreSQL support the concept of reverse key indexing as described
> here? I couldn't find any documentation on this yet.
> http://www.toadworld.com/platforms/oracle/w/wiki/11075.reverse-key-index-from-the-concept-to-internals.aspx
There's nothing built-in for th
Hi,
does PostgreSQL support the concept of reverse key indexing as described
here? I couldn't find any documentation on this yet.
http://www.toadworld.com/platforms/oracle/w/wiki/11075.reverse-key-index-from-the-concept-to-internals.aspx
Regards,
--
Sven R. Kunze
TBZ-PARIV GmbH, Bernsdorfer
11 matches
Mail list logo
