Re: [HACKERS] gincostestimate and hypothetical indexes

Julien Rouhaud writes: > On 01/12/2015 00:37, Tom Lane wrote: >> 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

[HACKERS] gincostestimate and hypothetical indexes

Hello, 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. Attached patch fixes this. I believe this should be back-patched as was a2095f7fb5a57ea1794f25d029756d9a140fd429. Regards.

Re: [HACKERS] gincostestimate and hypothetical indexes

Julien Rouhaud 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

Re: [HACKERS] gincostestimate and hypothetical indexes

On 01/12/2015 00:37, Tom Lane wrote: > Julien Rouhaud 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

Re: [HACKERS] gincostestimate

Jeff Janes jeff.ja...@gmail.com writes: The problem is that numEntries in src/backend/utils/adt/selfuncs.c is zero and eventually causes a division by zero and a cost estimate of nan. ... I don't know what the solution is. Simply setting numEntries to 1 if ginStats.nEntries zero solves this

[HACKERS] gincostestimate

Dear Hackers, A gin index created on an initially empty table will never get used until the table is vacuumed, which for a table with no update or delete activity could be forever unless someone manually intervenes. The problem is that numEntries in src/backend/utils/adt/selfuncs.c is zero and

Re: [HACKERS] gincostestimate

Itagaki Takahiro itagaki.takah...@gmail.com writes: On Wed, Sep 8, 2010 at 1:02 AM, Teodor Sigaev teo...@sigaev.ru wrote: Fixed, and slightly reworked to be more clear. Attached patch is based on your patch. The stats page is updated only in VACUUM. ANALYZE doesn't update the information at

Re: [HACKERS] gincostestimate

On Wed, Sep 8, 2010 at 1:02 AM, Teodor Sigaev teo...@sigaev.ru wrote: Fixed, and slightly reworked to be more clear. Attached patch is based on your patch. The patch will improve accuracy of plans using gin indexes. It only adds block-level statistics information into the meta pages in gin

Re: [HACKERS] gincostestimate

I also dropped the use of rd_amcache, instead having ginGetStats() Ok, I'm agree I didn't do anything about the questionable equations in gincostestimate. Those need to either be fixed, or documented as to why they're correct. Other than that I think this could be committed. Fixed, and

Re: [HACKERS] gincostestimate

I wrote: 1. The use of rd_amcache is very questionable. Attached is an alternate patch that I think you should give serious consideration to. The basic idea here is to only update the metapage stats data during VACUUM, and not bother with incremental updates during other operations. That gets

Re: [HACKERS] gincostestimate

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes: [ review of gincostestimate-0.19 ] I went through this patch, re-synced with current HEAD, and did some minor editorializing; a new version is attached. (Caution: I have not tested this beyond verifying that it still compiles.)

Re: [HACKERS] gincostestimate

OK, here's a review, as much as I was able to do it without understanding deeply how GIN works. The patch is context, applies cleanly to HEAD, compiles without warnings and passes regression tests. Using the script from http://archives.postgresql.org/pgsql-performance/2009-10/msg00393.php I

Re: [HACKERS] gincostestimate

On Fri, Jul 30, 2010 at 1:19 PM, Jan Urbański wulc...@wulczer.org wrote: The patch has lots of statements like if ( GinPageIsLeaf(page) ), that is with extra space between the outer parenthesis and the condition, which AFAIK is not the project style. I guess pgindent fixes that, so it's no big

Re: [HACKERS] gincostestimate

Jan, On Sun, 25 Jul 2010, Jan Urbaski wrote: On 02/07/10 14:33, Teodor Sigaev wrote: Patch implements much more accuracy estimation of cost for GIN index scan than generic cost estimation function. Hi, I'm reviewing this patch, and to begin with it I tried to reproduce the problem that

Re: [HACKERS] gincostestimate

On 26/07/10 12:58, Oleg Bartunov wrote: Jan, On Sun, 25 Jul 2010, Jan Urbaski wrote: On 02/07/10 14:33, Teodor Sigaev wrote: Patch implements much more accuracy estimation of cost for GIN index scan than generic cost estimation function. I was able to reproduce his issue, that is: select

Re: [HACKERS] gincostestimate

On 02/07/10 14:33, Teodor Sigaev wrote: Patch implements much more accuracy estimation of cost for GIN index scan than generic cost estimation function. Hi, I'm reviewing this patch, and to begin with it I tried to reproduce the problem that originally came up on -performance in

[HACKERS] gincostestimate

Patch implements much more accuracy estimation of cost for GIN index scan than generic cost estimation function. Basic idea is described on PGCon-2010: http://www.sai.msu.su/~megera/postgres/talks/pgcon-2010-1.pdf, pages 48-54. After discussion on PGCon, the storage of additional statistic