>
>
>
> This won't be immediately useful, but there's been a patch proposed for
> Postgres 15 to allow logging the plan of a running query [1]. Progress
> seems to have stalled a bit, but it seems like there was a fair amount of
> interest, so I wouldn't count it out yet. If you have thoughts on
about any operator here:
>
>
> https://stackoverflow.com/questions/4058731/can-postgresql-index-array-columns/29245753#29245753
>
> Regards,
> Flo
>
> On Wed, Mar 13, 2019 at 2:44 AM Corey Huinker
> wrote:
>
>> A client had an issue with a where that had a where c
A client had an issue with a where that had a where clause something like
this:
WHERE 123456 = ANY(integer_array_column)
I was surprised that this didn't use the pre-existing GIN index on
integer_array_column, whereas recoding as
WHERE ARRAY[123456] <@ integer_array_column
did cause the GIN
>
>
> Anyway, I think the partitioned table is the right and brilliant solution,
> because an index really isn't required. The actual pending partition will
> always remain quite small, and being a queue, it doesn't even matter how
> big it might grow, as long as new rows are inserted at the end
On Sun, Feb 24, 2019 at 5:43 PM Justin Pryzby wrote:
> On Sun, Feb 24, 2019 at 04:34:34PM -0500, Corey Huinker wrote:
> > I think your solution may be something like this:
> > 1. Create a new table, same columns, partitioned on the pending column.
> > 2. Rename your
>
> Also, the REINDEX command always fails with a deadlock because there is a
> row lock and a complete table lock involved.
>
> I consider this ultimately a bug, or at the very least there is room for
> improvement. And I am on version 11.1.
> regards,
> -Gunther
>
REINDEX doesn't work
On Sun, Feb 24, 2019 at 2:04 AM Justin Pryzby wrote:
> Some ideas:
>
> You could ALTER TABLE SET (fillfactor=50) to try to maximize use of HOT
> indices
> during UPDATEs (check pg_stat_user_indexes).
>
> You could also ALTER TABLE SET autovacuum parameters for more aggressive
> vacuuming.
>
>
