Back again,
I did some tests with our test machine, having a difficult query doing some
fancy stuff ;)
I made two versions, one using partitioned data, one, using unpartitioned
data, both having the same equivalent indexes. It's using two of those big
tables, one 28GB data and 17GB index, one 25G
Hi Ondrej,
Your solution has occurred to me, and wil even work in some cases. But in
more advanced queries, where for example, I would need the group ID again to
do some window function magic, this will sadly not work, without again doing
a reverse lookup to the ref_table to find it again. This sc
Hi,
On 8 December 2011 02:15, Christiaan Willemsen wrote:
> Currently, we are running into serious performance problems with our
> paritioning setup, because index lookups are mostly done on allpartions, in
> stead of the one partition it should know that it can find the needed row.
Planner is n
Hi there,
Currently, we are running into serious performance problems with our
paritioning setup, because index lookups are mostly done on allpartions, in
stead of the one partition it should know that it can find the needed row.
Simple example, were we have a partitioned tables
