Re: massive update on gin index

Em qua., 14 de set. de 2022 às 16:55, Tom Lane escreveu: > GIN does have a "pending list" of insertions not yet pushed into the main > index structure, and search performance will suffer if that gets too > bloated. I don't recall much about how to control that, but I think > vacuuming the table

Re: massive update on gin index

Marcos Pegoraro writes: > I know I have other options, and possibly better, but I was trying to > understand what happens with gin indexes, just that. GIN does have a "pending list" of insertions not yet pushed into the main index structure, and search performance will suffer if that gets too blo

Re: massive update on gin index

> > Did you try a simple array of phone numbers? If you really care about > mobile,work,home prepend the number with one of HMW. Easily stripped off > as necessary. I've had decent performance with arrays in the past. > I know I have other options, and possibly better, but I was trying to unders

Re: massive update on gin index

On 9/14/22 13:38, Guyren Howe wrote: You might consider defining a phone type that includes your “type” information, and just having an array of those, if you really want to do something like this. But a related table instead would be the obvious answer. Did you try a simple array of phone n

Re: massive update on gin index

You might consider defining a phone type that includes your “type” information, and just having an array of those, if you really want to do something like this. But a related table instead would be the obvious answer. > On Sep 14, 2022, at 12:33 , Marcos Pegoraro > wro

massive update on gin index

In a table with people's info I have 3 phone numbers, mobile, work and home. But then some have 2 mobiles, some have 2 work numbers, so decided to test it as an array of json. I know I could have another table for that, but I was just testing. So my original table had Mobile, Work, Home and all of