agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: [email protected]
Cc: Alexander Korotkov <[email protected]>
Subject: Re: GIN improvements part2: fast scan
Date: Wed, 12 Mar 2014 18:29:01 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAPpHfdvftaJq7www381naLw1=4u0h+qpXgWvNhcEB9HMVywbGg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfdticvY2+RGTxzQdrr4YSQie+vYGRDRBTuG1ZxBmjwGrOA@mail.gmail.com>
<CAPpHfduivz3MOA8_o+44n_Z0P-n+WCW=K1DrH+-g3gb-cbM2aA@mail.gmail.com>
<CAPpHfdtDfQ1ycU0oh650uB5ND4+OY-enbfkweGWzXryCWD4UZA@mail.gmail.com>
<CAPpHfdv792ZSWt_Tk+GzzsoNwm7ZGyomfrRiF7WuFN22LUVNUQ@mail.gmail.com>
<CAPpHfdtSuSoZS4SwYQu4Rc8NOwDHoX3DsLGaxJF9HZ6gW0TdVA@mail.gmail.com>
<[email protected]>
<CAPpHfdvMvEGXXUO0hpj=SU1tbVTpg1cP6kXjkyDqZpOD_9o7zQ@mail.gmail.com>
<[email protected]>
<CAPpHfdsMac=yQkkMi+HPN96EiCjvE1wBt9tveENq0tjti3r88w@mail.gmail.com>
<[email protected]>
<CAPpHfdvUmurpcqQ83vWr-SKAdWzrOMxH+_XDQ-A=9bQTpjrnxg@mail.gmail.com>
<CAPpHfdu18R9AG8-a_fB-eD2vpWtaydidM9TyRVFVY67R=SP7og@mail.gmail.com>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On 03/12/2014 12:09 AM, Tomas Vondra wrote:
> Hi all,
>
> a quick question that just occured to me - do you plan to tweak the cost
> estimation fot GIN indexes, in this patch?
>
> IMHO it would be appropriate, given the improvements and gains, but it
> seems to me gincostestimate() was not touched by this patch.
Good point. We have done two major changes to GIN in this release cycle:
changed the data page format and made it possible to skip items without
fetching all the keys ("fast scan"). gincostestimate doesn't know about
either change.
Adjusting gincostestimate for the more compact data page format seems
easy. When I hacked on that, I assumed all along that gincostestimate
doesn't need to be changed as the index will just be smaller, which will
be taken into account automatically. But now that I look at
gincostestimate, it assumes that the size of one item on a posting tree
page is a constant 6 bytes (SizeOfIptrData), which is no longer true.
I'll go fix that.
Adjusting for the effects of skipping is harder. gincostestimate needs
to do the same preparation steps as startScanKey: sort the query keys by
frequency, and call consistent function to split the keys intao
"required" and "additional" sets. And then model that the "additional"
entries only need to be fetched when the other keys match. That's doable
in principle, but requires a bunch of extra code.
Alexander, any thoughts on that? It's getting awfully late to add new
code for that, but it sure would be nice somehow take fast scan into
account.
- Heikki
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (91+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: GIN improvements part2: fast scan
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox