HI, all!
> On 27.06.2023 16:19, Alena Rybakina wrote:
>> Thank you for your feedback, your work is also very interesting and
>> important, and I will be happy to review it. I learned something new
>> from your letter, thank you very much for that!
>>
>> I analyzed the buffer consumption when I ran control regression tests
>> using my patch. diff shows me that there is no difference between the
>> number of buffer block scans without and using my patch, as far as I
>> have seen. (regression.diffs)
>>
>>
>> In addition, I analyzed the scheduling and duration of the execution
>> time of the source code and with my applied patch. I generated 20
>> billion data from pgbench and plotted the scheduling and execution
>> time depending on the number of "or" expressions.
>> By runtime, I noticed a clear acceleration for queries when using the
>> index, but I can't say the same when the index is disabled.
>> At first I turned it off in this way:
>> 1)enable_seqscan='off'
>> 2)enable_indexonlyscan='off'
>> enable_indexscan='off'
>>
>> Unfortunately, it is not yet clear which constant needs to be set
>> when the transformation needs to be done, I will still study in
>> detail. (the graph for all this is presented in graph1.svg
I finished comparing the performance of queries with converted or
expressions and the original ones and found that about 500 "OR"
expressions have significantly noticeable degradation of execution time,
both using the index and without it (you can look at
time_comsuption_with_indexes.png and time_comsuption_without_indexes.html )
The test was performed on the same benchmark database generated by 2
billion values.
I corrected this constant in the patch.
--
Regards,
Alena Rybakina
Postgres Professional
