On 4 April 2017 at 14:07, Johann Spies wrote:
> While updating our database which includes a lot of deletions where a lot
> of foreign key references are involved we found that in the case of two
> tables the indexes are ignored and it slow down the process a lot.
> ...
>
>
> Why would that be?
On 04/25/2017 08:28 AM, Johann Spies wrote:
On 24 April 2017 at 15:17, Tomas Vondra wrote:
On 04/24/2017 08:48 AM, Johann Spies wrote:
Why would the planner prefer the use the gin index and not the btree
index in this case?
You'll need to show what queries are you running - that's a quite
On 25 April 2017 at 18:28, Johann Spies wrote:
> On 24 April 2017 at 15:17, Tomas Vondra wrote:
>> On 04/24/2017 08:48 AM, Johann Spies wrote:
>>>
>>>
>>> Why would the planner prefer the use the gin index and not the btree
>>> index in this case?
>>>
>>
>> You'll need to show what queries are yo
On 24 April 2017 at 15:17, Tomas Vondra wrote:
> On 04/24/2017 08:48 AM, Johann Spies wrote:
>>
>>
>> Why would the planner prefer the use the gin index and not the btree
>> index in this case?
>>
>
> You'll need to show what queries are you running - that's a quite important
> piece of informatio
On 04/24/2017 08:48 AM, Johann Spies wrote:
Why would the planner prefer the use the gin index and not the btree
index in this case?
You'll need to show what queries are you running - that's a quite
important piece of information, and I don't see it anywhere in this
thread. Seeing explain p
> On Wed, Apr 5, 2017 at 6:40 AM, Johann Spies wrote:
>>
>> On 4 April 2017 at 14:07, Johann Spies wrote:
>>
>> > Why would that be?
>>
>> To answer my own question. After experimenting a lot we found that
>> 9.6 uses a parallel seqscan that is actually a lot faster than using
>> the index on th
On Wed, Apr 5, 2017 at 6:40 AM, Johann Spies wrote:
> On 4 April 2017 at 14:07, Johann Spies wrote:
>
> > Why would that be?
>
> To answer my own question. After experimenting a lot we found that
> 9.6 uses a parallel seqscan that is actually a lot faster than using
> the index on these large t
On 4 April 2017 at 14:07, Johann Spies wrote:
> Why would that be?
To answer my own question. After experimenting a lot we found that
9.6 uses a parallel seqscan that is actually a lot faster than using
the index on these large tables.
This, to us was a surprise!
Regards
Johann
--
Because e
While updating our database which includes a lot of deletions where a lot
of foreign key references are involved we found that in the case of two
tables the indexes are ignored and it slow down the process a lot.
Here are stats about those two tables:
relname seq_scan seq_tup_read idx_scan idx_tu
