>> Thanks for the reply, but that did not seem to help.
> I tried to replicate this as follows:
> --- CUT ---
> create table request(objectid text, productid int, data jsonb); create index
> on request(objectid, productid);
> CREATE OR REPLACE FUNCTION public.steve1(param_requestid text[],
>
> > Here is the function I'm having difficulties with:
> > CREATE OR REPLACE FUNCTION public.steve1(param_requestid text[],
> > param_productid integer DEFAULT 1) RETURNS TABLE(objectid text, n
> > text, v text, vt integer) LANGUAGE sql AS $function$
> > SELECT objectid::text
> >
I'm not sure if I should send this to pgsql-performance or pqsql-general so
hopefully I'm sending to the correct one.
Table definition:
shared=> \d request
Table "public.request"
Column |Type | Collation | Nullable |
Default
Postgres RDS running in AWS. PostgreSQL 16.8 on aarch64-unknown-linux-gnu,
compiled by gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-17), 64-bit
Table definition
Table: request
Column |Type | Collation | Nullable |
Default
--+
Didn't mention- this is Aurora Postgres version 14.6 if that matters for my
question. Thanks
From: Dirschel, Steve
Sent: Wednesday, August 7, 2024 12:06 PM
To: [email protected]
Subject: Postgres index usage
I've found multiple postings out there saying you
I've found multiple postings out there saying you can query pg_stat_all_indexes
and look at idx_scan to know if an index has been used by queries. I want to
be 100% sure I can rely on that table/column to know if an index has never been
used.
I queried that table for a specific index and idx_s
Relatively new to Postgres. Running into a locking situation and I need to
make sure I understand output. I found this query to show a lock tree:
wldomart01a=> WITH
wldomart01a-> RECURSIVE l AS (
wldomart01a(> SELECT pid, locktype, mode, granted,
wldomart01a(>
On Wed, Oct 06, 2021 at 06:00:07PM +, Dirschel, Steve wrote:
> • When I did an explain on the delete I could see it was full
scanning the table. I did a full scan of the table interactively in less than 1
second so the long runtime was not due to the full tables
On 10/6/21 14:00, Dirschel, Steve wrote:
Question:
How would one troubleshoot this issue in Postgres as to why the delete was
running so long? My background is Oracle and there are various statistics I
may look at:
· One could estimate the number of logical reads the delete should do
Question:
How would one troubleshoot this issue in Postgres as to why the delete was
running so long? My background is Oracle and there are various statistics I
may look at:
• One could estimate the number of logical reads the delete should do
based on expected number of rows to delete,
New to Postgres, Oracle background. With Oracle the amount of work a query
does is tracked via logical reads. Oracle tracks logical and physical reads
differently than Postgres. With Oracle a physical read is always considered a
logical read. So if a query reads 5 blocks are all 5 are read f
11 matches
Mail list logo
