Hey all,
Lots of interesting suggestions! I'm loving it.
Just came back to this a bit earlier today and made a sample table to see
what non-index performance would be. Constructed data just like above (used
12M rows and 80% true for all 100 boolean columns)
Here's an analyze for what I'd expect
On Wed, Apr 20, 2016 at 11:54 AM, Teodor Sigaev wrote:
>>
>> The obvious thing seems to make a table with ~100 columns, with 1 column
>> for each boolean property. Though, what type of indexing strategy would
>> one use on that table? Doesn't make sense to do BTREE. Is there a better
>> way to str
On Wed, Apr 20, 2016 at 11:41 AM, Rob Imig wrote:
> Hey all,
>
> New to the lists so please let me know if this isn't the right place for
> this question.
>
> I am trying to understand how to structure a table to allow for optimal
> performance on retrieval. The data will not change frequently so
After remodeling a table we have some performance problems.
The Original tables have much more fields and we thought it came from these
many fields. After some testing I tried these test layout and the
performance problem is not solved.
Postgresql 9.3.12
Former DB-Layout was table _mast
