On Tue, Feb 13, 2024 at 2:26 PM veem v wrote:
> Can the optimizer, only scan the TABLE1 using ACCESS criteria "
> TABLE1.MID in ()" or "TABLE1.CID in ()" which will be catered by
> two different index i.e one index on column "MID" and other on column "CID"?
>
Yes:
greg=# create table t
On Tue, 13 Feb 2024 at 20:59, Peter J. Holzer wrote:
> For some kinds of queries a composite index can be dramatically faster.
> While Postgres can combine indexes that means scanning both indexes and
> combining the result, which may need a lot more disk I/O than scanning a
> composite index. In
On 2024-02-12 11:46:35 -0500, Greg Sabino Mullane wrote:
> If PR_ID is a must in the Join criteria between these table tables table1,
> table2 in all the queries, then is it advisable to have a composite index
> like (pr_id, mid), (pr_id,cid) etc rather than having index on individual
> Is there any way to track those historical executions and be able to find
the exact root cause of the slow executions confidently?
https://www.postgresql.org/docs/current/auto-explain.html
auto_explain.log_min_duration = '5s' ## or large enough to capture your
quickest one
Do NOT enable auto_e
Thank You.
On Mon, 12 Feb 2024 at 22:17, Greg Sabino Mullane
wrote:
> Sure will try to test and see how it behaves when the number of
>> simultaneous queries (here 32/4=8 concurrent queries) exceed the
>> max_parallel_workers limit. Though I am expecting the further queries
>> exceeding the limi
>
> When the user clicks to the second page , it will see the next set of rows
> i.e 100 to 200 and next will see 200 to 300 and so on till the result set
> finishes.
>
As others have pointed out, that still makes no sense. You will either fail
to show certain rows completely, or have a stale view
Am Sun, Feb 11, 2024 at 12:53:10PM +0530 schrieb veem v:
> >> Pagination is already a hard problem, and does not even make sense when
> > combined with "a continuous stream of inserts". What should the user see
> > when they click on page 2?
> >
>
> When the user clicks to the second page , it wil
> On 10 Feb 2024, at 20:38, veem v wrote:
>
> Hello,
> We want to have the response time in <1 sec for our UI search query
> requirement. These will be pagination queries. These read queries will be on
> big transaction tables (will have ~500+ attributes approx will have approx.
> r
Thank you So much Greg.
Will try to test the things as max as possible. I was trying to see
basically, if any obvious things we should take care of before designing a
system for satisfying such requirements. As you pointed few things , i am
trying t answer those below
On Sun, 11 Feb 2024 at 10:43
There is a lot to unpack here. I'm going to take a quick pass, but you
ought to consider getting some custom expert help.
On Sat, Feb 10, 2024 at 2:39 PM veem v wrote:
> ... These will be pagination queries. These read queries will be on big
> transaction tables (will have ~500+ attributes appro
Hello,
We want to have the response time in <1 sec for our UI search query
requirement. These will be pagination queries. These read queries will be
on big transaction tables (will have ~500+ attributes approx will have
approx. rows size of ~1KB) having a continuous stream of inserts consu
11 matches
Mail list logo
