On Mon, 13 Jun 2005, Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
... So, if index is defined as 'using gist (a,b,c)' then, in
principle, GiST index can speed up queries like 'a=V1 and c=V2'. But
it will not usable for queries ( b=V3 and c=V2 ). By the way, instead
of '=' operation
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> ... So, if index is defined as 'using gist (a,b,c)' then, in
> principle, GiST index can speed up queries like 'a=V1 and c=V2'. But
> it will not usable for queries ( b=V3 and c=V2 ). By the way, instead
> of '=' operation may be used other operations. Nu
Alvaro Herrera wrote:
> On Tue, May 17, 2005 at 09:39:20AM +0800, Christopher Kings-Lynne wrote:
> >
> >
> > Bruce Momjian wrote:
> > >If people have GIST TODOs, please post them.
> >
> > Concurrency :)
>
> And WAL support.
Already there:
* Add WAL index reliability improvement to non
On Tue, May 17, 2005 at 09:39:20AM +0800, Christopher Kings-Lynne wrote:
>
>
> Bruce Momjian wrote:
> >If people have GIST TODOs, please post them.
>
> Concurrency :)
And WAL support.
--
Alvaro Herrera ()
"No necesitamos banderas
No reconocemos fronteras" (Jorge González)
-
Bruce Momjian wrote:
If people have GIST TODOs, please post them.
Concurrency :)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
If people have GIST TODOs, please post them.
---
Teodor Sigaev wrote:
> About page splitting algorithm in GiST in multikey case. For the beginning,
> page
> is splitted by calling pickSplit method of key of first column (p
About page splitting algorithm in GiST in multikey case. For the beginning, page
is splitted by calling pickSplit method of key of first column (pickSplit method
is defined for opclass and it is a user function), then it try to find equal
values of first column in left and right pages ( gist.c
Tom Lane <[EMAIL PROTECTED]> writes:
> I think it would be easy to change the planner and btree to handle
> this (where "easy" means "I remember where all the skeletons are
> buried"). But I don't know the gist code hardly at all. Can anyone
> offer an informed opinion on whether gist can hand
On Sun, 15 May 2005, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Bruce Momjian writes:
Hmm. That particular case will work, but the planner believes that only
consecutive columns in the index are usable --- that is, if you have
quals for a and c but not for b, it will think that the co
Greg Stark <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>>> Hmm. That particular case will work, but the planner believes that only
>>> consecutive columns in the index are usable --- that is, if you have
>>> quals for a and c but not for b, it will think that the condition for c
>>> isn't
On Thu, 12 May 2005 17:40:06 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>the planner believes that only
>consecutive columns in the index are usable --- that is, if you have
>quals for a and c but not for b, it will think that the condition for c
>isn't usable with the index. This is true for btre
Bruce Momjian writes:
> > Hmm. That particular case will work, but the planner believes that only
> > consecutive columns in the index are usable --- that is, if you have
> > quals for a and c but not for b, it will think that the condition for c
> > isn't usable with the index. This is true fo
Tom Lane wrote:
> "Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> > If I have on-disk bitmap
> > ON (a, b, c)
> > will the planner pick an index scan for
> > WHERE a = 42 AND b = 'foo'
> > (i.e. only part of the index attributes are involved)? Any modifications
> > needed to achieve this
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Plan B would be to remove that restriction and teach btree and gist to
>> cope. While a btree couldn't use a nonconsecutive restriction as part
>> of its where-to-scan logic, I don't see any good reason why it couldn'
Tom Lane <[EMAIL PROTECTED]> writes:
> Plan B would be to remove that restriction and teach btree and gist to
> cope. While a btree couldn't use a nonconsecutive restriction as part
> of its where-to-scan logic, I don't see any good reason why it couldn't
> still perform the test before returnin
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> If I have on-disk bitmap
> ON (a, b, c)
> will the planner pick an index scan for
> WHERE a = 42 AND b = 'foo'
> (i.e. only part of the index attributes are involved)? Any modifications
> needed to achieve this functionality?
Hmm. That
* Tom Lane <[EMAIL PROTECTED]> [12.05.2005 23:09]:
> 1. Be sure that all the indexable WHERE conditions are passed to the
>indexscan as indexquals. This might be, say,
> WHERE a = 42 and b = 'foo'
If I have on-disk bitmap
ON (a, b, c)
will the planner pick an index scan for
"Victor Y. Yegorov" <[EMAIL PROTECTED]> writes:
> I have questions on how to implement on-disk bitmap scan.
I think your best plan might be
1. Be sure that all the indexable WHERE conditions are passed to the
indexscan as indexquals. This might be, say,
WHERE a = 42 and b = 'foo'
2.
Greetings.
I have questions on how to implement on-disk bitmap scan.
I've been working on on-disk bitmaps as an ordinary Index Access Method, but
now it's clear to me, that it'll lose all it's strengths this way. One on-disk
bitmap has exactly one list of indexed table's TIDs and potentially unl
19 matches
Mail list logo
