On Thu, Aug 31, 2023 at 11:06 AM Maxim Boguk wrote:
> With the default value of autovacuum_vacuum_scale_factor (The default is
> 0.2 (20% of table size).) index will collect like 100M outdated/dead index
> entries before autovacuum kicks in and cleans them all (in a worst case),
> and of course
On Wed, Aug 30, 2023 at 8:43 PM jayaprabhakar k
wrote:
>
>
> On Tue, Aug 29, 2023, 12:43 PM Jeff Janes wrote:
>
>> On Mon, Aug 28, 2023 at 8:33 PM jayaprabhakar k
>> wrote:
>>
>>>
>>> Since we are only interested in the pending tasks, I created a partial
>>> index
>>> `*"tasks_pending_status_c
Thanks Maxim, that's something we are considering now - keep the in
progress tasks in one table and periodically move the old and completed
tasks to an archive table.
We could use a view that unions them for most queries.
I'm not sure if that's the best alternative though, and we want to know if
t
On Wed, Aug 30, 2023 at 1:31 PM Rondat Flyag wrote:
> Hi and thank you for the response.
>
> I tried VACUUM ANALYZE for three tables, but without success. I also tried
> to set enable_seqscan=off and the query took even more time. If I set
> enable_sort=off then the query takes a lot of time and
> At any moment, there are *around 1000-1500 tasks in pending statuses*
> (Init + InProgress) out of around 500 million tasks.
>
> Now, we have a task monitoring query that will look for all pending tasks
> that have not received any update in the last n minutes.
>
> ```
> SELECT [columns list]
>
Hi,
I'm from the Hibernate team (Java ORM) and a user recently reported that
a change in our SQL rendering affected his query plans in a bad way.
In short, we decided to model certain constructs in our ORM with "nested
joins" i.e. using parenthesis to express the join order. This is what we
