tion? Or does it actually perform a deletion?
Cheers
Jim
--
Jim Vanns
Principal Production Engineer
Industrial Light & Magic, London
after) on prod_main
it'll fire also on dev_main? I can't find anything in the
documentation that suggests either way nor can I see an explicit
EXCLUDING option to be sure triggers aren't copied.
Does anyone know?
Cheers,
Jim
--
Jim Vanns
Principal Production Engineer
Industria
I just wrote a little test case... it appears not. Triggers aren't
fired in the temporary table.
Jim
On Thu, 25 May 2023 at 14:06, Jim Vanns wrote:
>
> Hi everyone,
>
> When basing a temporary table of a source table, are triggers included
> by default? I have this s
evice_N; <-- The dynamically created partition
We don't know the device names and thus partitions up front, hence the need
for dynamic creation. How do you go about doing this or is it folly!?
Cheers
Jim
--
Jim Vanns
Principal Production Engineer
Industrial Light & Magic, London
Yeah, that's a known concern - hence the evaluation as part of the list
vs. hash comparison ;)
Jim
On Thu, 1 Jun 2023 at 14:32, Tom Lane wrote:
> Jim Vanns writes:
> > Here's the general approach we have, without code and with hypothetical
> > model, since
nt runs in under a
minute.
What I need is a way to see into this statement as it executes to confirm
my suspicion - does anyone have any tips on that?
Cheers
Jim
--
Jim Vanns
Principal Production Engineer
Industrial Light & Magic, London
t;
> Adrian Klaver writes:
> > On 1/16/24 09:45, Jim Vanns wrote:
> >> I have a slow (CPU bound) DELETE statement I'm attempting to debug and I
> >> suspect that its actually the ON DELETE CASCADE on the foreign key thats
> >> causing it.
>
> 99
After dropping the constraint entirely the DELETE completes in 4
minutes (the same time as the dry-run using SELECT against the
function instead of a DELETE). A marked improvement on 3 hours
followed by a pg_cancel_backend()!
Jim
On Thu, 18 Jan 2024 at 16:37, Jim Vanns wrote:
>
> Hi Tom/
thing?
I understand that I can create a Linux tmpfs partition for a tablespace for
the temporary tables and that may speed up the TRUNCATE but that seems like
a hack and I'd rather not do it at all if it's avoidable.
Thanks for your help,
Jim
PS. PG version in use is 15.4 if that matters
I've been able to observe that the performance degradation with TRUNCATE
appears to happen when other ancillary processes are running that are also
heavy users of temporary tables. If I used an exclusive tablespace, would
that improve things?
Cheers
Jim
On Wed, 31 Jul 2024 at 19:27, Jim
pect to the sessions.
Cheers,
Jim
--
Jim Vanns
Principal Production Engineer
Industrial Light & Magic, London
Sorry, PG15.
Jim
On Thu, 1 Aug 2024 at 20:25, Adrian Klaver
wrote:
> On 8/1/24 12:12, Tom Lane wrote:
> > Jim Vanns writes:
> >> I have two sessions, each creating a temporary table of the same name -
> >> 'foobar'. Why would a vacuum of 'foobar&#x
I don't at hand, but the query I used to identify this was;
SELECT state, pid, pg_blocking_pids(pid), query
FROM pg_stat_activity
WHERE backend_type='client backend';
On Thu, 1 Aug 2024 at 20:12, Tom Lane wrote:
> Jim Vanns writes:
> > I have two sessions, each creat
PG 15.4
On Thu, 1 Aug 2024 at 22:27, Ron Johnson wrote:
> PG 15.0 or 15.7?
>
> On Thu, Aug 1, 2024 at 3:58 PM Jim Vanns wrote:
>
>> Sorry, PG15.
>>
>> Jim
>>
>> On Thu, 1 Aug 2024 at 20:25, Adrian Klaver
>> wrote:
>>
>>> On 8/1/2
Official PGDB RPM build for Centos 7.9
On Thu, 1 Aug 2024 at 23:31, Adrian Klaver
wrote:
> On 8/1/24 15:13, Jim Vanns wrote:
> > PG 15.4
>
> Community edition or some variant?
>
>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>
--
Jim Vann
*PGDG
On Fri, 2 Aug 2024 at 08:38, Jim Vanns wrote:
> Official PGDB RPM build for Centos 7.9
>
> On Thu, 1 Aug 2024 at 23:31, Adrian Klaver
> wrote:
>
>> On 8/1/24 15:13, Jim Vanns wrote:
>> > PG 15.4
>>
>> Community edition or some variant?
>&g
acuum_vacuum_scale_factor = 0.1 # 10%
autovacuum_analyze_scale_factor = 0.1 # 10%
autovacuum_vacuum_insert_scale_factor = 0.1 # 10%
autovacuum_naptime = 60
autovacuum_max_workers = 8
# Give autovacuum more credits to ensure a better chance at scanning
autovacuum_vacuum_cost_limit = 2000 # 10x the default
Thanks for y
Aug 2024 at 11:26, Jim Vanns wrote:
>
> Hi pggen community!
>
> I am struggling with this error almost daily now and despite various efforts,
> not succeeding in avoiding or dealing with it;
>
> ERROR: multixact "members" limit exceeded
> DETAIL: This comma
e's a shareable, MRP;
https://dbfiddle.uk/OKs_7HWv
Is there any trick I can do to get the planner to make use of the
conditional/partial index? Or is this simply an unoptimised code path yet
to be exploited!?
Cheers,
Jim
--
Jim Vanns
Principal Production Engineer
Industrial Light & Magic, London
affect the behaviour of the planner to disregard workers?
Cheers
Jim
--
Jim Vanns
Principal Production Engineer
Industrial Light & Magic, London
Thanks for the reply Laurenz. Inline replies follow...
On Tue, 28 Jan 2025 at 04:47, Laurenz Albe wrote:
>
> On Mon, 2025-01-27 at 18:08 +0000, Jim Vanns wrote:
> > If I have a function that is marked 'stable parallel safe' and returns
> > a table, can a calling f
21 matches
Mail list logo
