On Fri, Aug 26, 2022 at 1:34 PM Maxim Boguk <maxim.boguk@gmail.com> wrote:
>
>
> On Thu, Aug 25, 2022 at 11:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> PG Bug reporting form <noreply@postgresql.org> writes:
>> > I found very weird situation with size of highly selective partial hash
>> > indexes (they has almost same size as full table hash index).
>>
>> hashbuild() sets up the initial hash index size based on estimating
>> the current number of rows in the table, without any correction for
>> partial-index selectivity. I don't find this to be a bug particularly.
>> The odds of making things worse via a bad estimate seem at least as
>> high as the odds of making things better.
>>
>> regards, tom lane
>
>
> Sometimes it lead to unexpected results, for hash indexes most common (imho) use case is indexing long text/varchar
columnson big tables where they provide substantial size reduction over usual btree indexes (or in extreme case of very
longtest columns - btree cannot be used at all). Now in the case of a partial hash index over a huge table (with highly
selectiveconditions thus covering only a tiny part of rows) - size of resulting hash index could be a huge surprise (in
thepractical case where I found this issue it was 200MB hash index with only 5 rows in it).
> Are most pages of hash index in that case will be completely empty and almost never touched by the database (thus
wastingonly disk space) or the resulting hash index will have very low rows per index page ratio (thus inefficiently
useshared buffers as well)?
>
I think it would be later, less number of rows per index page but you
can check/verify with hash functions provided by pageinspect module
[1]. In the case, you mentioned in your email, I have checked it is
distributed over 10 different bucket pages. I think if the number of
rows are so less, if you create such an index beforehand then you may
not see large number of empty pages.
[1] - https://www.postgresql.org/docs/devel/pageinspect.html#id-1.11.7.34.10
--
With Regards,
Amit Kapila.