Hi All
I did final research and saw that the difference between best and worst
cases is indeed really small.
I want to thank you guys for your time and efforts.
Best regards.
вт, 2 нояб. 2021 г. в 18:04, Pavel Borisov :
> вт, 2 нояб. 2021 г. в 16:04, Hayk Manukyan :
>
>> Tomas Von
Tomas Vondra
> Are you suggesting those are not the actual best/worst cases and we
> should use some other indexes? If yes, which ones?
I would say yes.
In my case I am not querying only sequence column.
I have the following cases which I want to optimize.
1. Select * from Some_table where job =
I agree with the above mentioned.
The only concern I have is that we compare little wrong things.
For read we should compare
(job, nlp, year, sequence) AND (job, nlp, year, Scan_ID) and (job, nlp,
year, issue_flag ) VS (job, nlp, year, sequence, Scan_ID, issue_flag)
OR (job, nlp, year INCLUDE(
Hi all
First of all thank you all for fast and rich responses, that is really nice.
I don't have that deep knowledge of how postgres works under the hood so I
will try to explain more user side.
I want to refer for some points mentioned above.
- First INCLUDE statement mostly eliminates the neces
index and will manage red part only once for
all three cases.
Those it make sense ?
If you need more discussion we can have short call I will try to explain
you in more detailed way.
best regards
пн, 25 окт. 2021 г. в 19:33, Tomas Vondra :
> Hi,
>
> On 10/25/21 16:07, Hayk Manukyan wrote:
&
Hi everyone. I want to do some feature request regarding indexes, as far as
I know this kind of functionality doesn't exists in Postgres. Here is my
problem :
I need to create following indexes:
Create index job_nlp_year_scan on ingest_scans_stageing
(`job`,`nlp`,`year`,`scan_id`);
