On Thu, Jan 12, 2023 at 01:33:56AM -0600, Ron wrote:
> On 1/12/23 01:11, Tom Lane wrote:
> > Ron writes:
> > > On 1/12/23 00:07, Tom Lane wrote:
> > > > No, not directly, but you could look at EXPLAIN ANALYZE to see which
> > > > of the RI triggers is eating the time.
> > > Good to know, but even
On 1/12/23 01:11, Tom Lane wrote:
Ron writes:
On 1/12/23 00:07, Tom Lane wrote:
No, not directly, but you could look at EXPLAIN ANALYZE to see which
of the RI triggers is eating the time.
Good to know, but even deleting one day of data (90,000 rows using an index
scan on the date field) takes
Ron writes:
> On 1/12/23 00:07, Tom Lane wrote:
>> No, not directly, but you could look at EXPLAIN ANALYZE to see which
>> of the RI triggers is eating the time.
> Good to know, but even deleting one day of data (90,000 rows using an index
> scan on the date field) takes forever.
So delete a re
On 1/12/23 00:07, Tom Lane wrote:
Ron writes:
Deletes are slow in one table with many indices and FK references. That's
not surprising, but it's *VERY* slow, and I'm trying to figure out why.
Is there any EXPLAIN option which shows what "query plans" Pg is using when
checking FK references (ind
On Wed, Jan 11, 2023 at 10:13:11PM -0800, Christophe Pettus wrote:
>
> Also, IIRC, the SELECTs generated to do foreign key checks do appear in
> pg_stat_statements, so that might provide a guide to ones that are consuming
> an unusually large amount of resources.
Yes, but you need to have pg_stat_
> On Jan 11, 2023, at 22:07, Tom Lane wrote:
> No, not directly, but you could look at EXPLAIN ANALYZE to see which
> of the RI triggers is eating the time. It's not going to be hard to
> figure out which one(s) are using indexed plans and which are not.
Also, IIRC, the SELECTs generated to d
Ron writes:
> Deletes are slow in one table with many indices and FK references. That's
> not surprising, but it's *VERY* slow, and I'm trying to figure out why.
> Is there any EXPLAIN option which shows what "query plans" Pg is using when
> checking FK references (index scan, seq scan, etc) du
Pg 12.11
Deletes are slow in one table with many indices and FK references. That's
not surprising, but it's *VERY* slow, and I'm trying to figure out why.
Is there any EXPLAIN option which shows what "query plans" Pg is using when
checking FK references (index scan, seq scan, etc) during dele
On 1/11/23 15:06, Adrian Klaver wrote:
On 1/11/23 13:00, Ron wrote:
How do I get clock_timestamp() to display the time in a different time zone?
This is America/Chicago, but I'd like to display it in a different TZ.
psql (12.12 (Ubuntu 12.12-1.pgdg18.04+1))
postgres=# DO $$
postgres$# BEGIN
po
Fred Habash writes:
> According to pgstattuple, dead_tuple_count = 0. If this is the case, then
> what other explanations do we have?
Could be that old tuple(s) now require freezing.
> I mean, how can I find out what blocker
> session is holding the bufferpin to terminate it?
I don't think ther
On 1/11/23 13:00, Ron wrote:
How do I get clock_timestamp() to display the time in a different time
zone?
This is America/Chicago, but I'd like to display it in a different TZ.
psql (12.12 (Ubuntu 12.12-1.pgdg18.04+1))
postgres=# DO $$
postgres$# BEGIN
postgres$# RAISE NOTICE '%', clock_timest
How do I get clock_timestamp() to display the time in a different time zone?
This is America/Chicago, but I'd like to display it in a different TZ.
psql (12.12 (Ubuntu 12.12-1.pgdg18.04+1))
postgres=# DO $$
postgres$# BEGIN
postgres$# RAISE NOTICE '%', clock_timestamp();
postgres$# END$$;
NOTICE
Hello,
I have an extension that contains a configuration table with a before
insert trigger that I setup to dump with pg_extension_config_dump().
Because the table and trigger are setup during CREATE EXTENSION time
emitted by the dump, and the dumped table is then COPY'd outside of that,
the trigg
According to pgstattuple, dead_tuple_count = 0. If this is the case, then
what other explanations do we have? I mean, how can I find out what blocker
session is holding the bufferpin to terminate it?
SELECT * FROM pgstattuple('.*'::regclass);
table_len | tuple_count | tuple_len | tuple_p
Fred Habash writes:
> pg_locks shows no blockers while this is happening. This view shows a
> constant 13 sessions running SELECT statements on this table posting
> AccessShareLock. Of course, these is also the AV sessions
> with ShareUpdateExclusiveLock
> ...
> Why is AV blocked by bufferpin give
I have a very small table of 28 rows that is less than 10kB. One of the AV
workers has been stuck autovac'ing it for over 20 hrs now with no progress
in heap blocks scanned or vac'd. I terminated the AV worker and ran a
manual vac which also ended up stuck waiting for a bufferpin.
pg_locks shows n
On Tue, Jan 10, 2023 at 07:01:24PM +0100, Wiwwo Staff wrote:
> Hi!
> Happy new (gregorian calendar) year!
>
> Somehow related to the proposal of having a `psql --idle` option, is there
> a way to disallow the command `\!` (and anything of the likes in psql?
>
> Sure, I can set the SHELL env var a
On 1/9/23 11:23, Torsten Förtsch wrote:
On Mon, Jan 9, 2023 at 10:59 AM Adrien Nayrat
mailto:adrien.nay...@anayrat.info>> wrote:
* We can't perform PITR on a cluster without any activity since 13
* It seems creating restore point doesn't record a timestamp in wal.
I have a cron job th
Thank you Bhaumik,
I was also searching for and found one - pgwatch from cybertec.
Has anybody got views or feedback on this one? Has anybody used it for
monitoring purposes?
Thank you all for your valuable feedback and suggestions.
Regards
On Tue, 10 Jan 2023, 16:47 Bhautik Chudasama,
wrote:
19 matches
Mail list logo
