On Tue, 18 May 2021 at 08:42, wrote:
> Running delete from table1 where id = 48938 the trigger for constraint runs
> for 20 seconds
>
> Event when doing a simple select from table2 where table1_id = 48938 takes
> about 8 seconds
Does EXPLAIN show it uses a seq scan for this 8-second SELECT?
If
Good day
I'm struggling with a Postgres 13 performance issue and nothing I do seem to
help.
I have two tables with one having a foreign key to the other. It happens to
be for this one client the foreign key is always null, so no violation would
be possible. When deleting from the one table
Hello David,
> I really think you're driving yourself down a difficult path by
> expecting queries with whole-row vars to be optimised just as well as
> using select * or explicitly listing the columns.
Yes, I was expect that. I use whole-row because do not want repeat all
10+ columns at select.
Hello David,
Saturday, May 15, 2021, 5:52:47 PM, you wrote:
> On Sun, 16 May 2021 at 02:34, Eugen Konkov wrote:
>> I found a case when `not assigning a ressortgroupref to the whole-row var`
>> cause
>> wrong window function calculations.
>>
>> I use same query. The difference come when I
On Sat, 15 May 2021 at 00:39, KES wrote:
>
> Thank you for detailed explanation. I glad to hear that I can use aliases and
> this will be recognized and optimization is applied.
>
> >We'd need some sort of ability to assign ressortgroupref to a particular
> >column within a
> whole-row var
> Cou
On Sun, 16 May 2021 at 02:34, Eugen Konkov wrote:
> I found a case when `not assigning a ressortgroupref to the whole-row var`
> cause
> wrong window function calculations.
>
> I use same query. The difference come when I wrap my query into
> function. (see full queries in attachment)
>
>
