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 with one with a bit
>> of te
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 patch fixes this. I believe t
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 back-patched as was
> a2095f7fb5a57
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.
Jeff Janes 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 particular pro
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 e
Itagaki Takahiro writes:
> On Wed, Sep 8, 2010 at 1:02 AM, Teodor Sigaev 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 all.
ANALYZE doesn't scan indexes,
On Wed, Sep 8, 2010 at 1:02 AM, Teodor Sigaev 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 indexes. Data-level
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 slig
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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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.)
> Codewise I have one qu
On Fri, Jul 30, 2010 at 1:19 PM, Jan Urbański 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
> deal.
It's bet
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
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 i
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 orig
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
http://archiv
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 info
17 matches
Mail list logo
