From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gincostestimate and hypothetical indexes |
Date: | 2015-11-30 23:37:48 |
Message-ID: | 28068.1448926668@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> writes:
> I figured out that it's not possible to use a hypothetical gin index, as
> the gincostestimate function try to retrieve some statistical data from
> the index meta page.
Good point.
> Attached patch fixes this. I believe this should be back-patched as was
> a2095f7fb5a57ea1794f25d029756d9a140fd429.
I don't much care for this patch though. The core problem is that just
returning all zeroes seems quite useless: it will probably result in silly
cost estimates. The comment in the patch claiming that this would be the
situation in a never-vacuumed index is wrong, because ginbuild() updates
those stats too. But I'm not sure exactly what to do instead :-(.
Ideally we'd put it on the head of the hypothetical-index plugin to invent
some numbers, but I dunno if we want to create such an API or not ... and
we certainly couldn't back-patch such a change.
Maybe we could do something along the lines of pretending that 90% of the
index size given by the plugin is entry pages? Don't know what a good
ratio would be exactly, but we could probably come up with one with a bit
of testing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-11-30 23:45:54 | Re: 9.5Beta1 psql wrapped format expanded output |
Previous Message | Michael Paquier | 2015-11-30 23:31:14 | Re: Remaining 9.5 open items |