On Tue, Feb 15, 2011 at 10:16 AM, Michael Glaesemann
<g...@seespotcode.net>wrote:

> Providing the table definition, queries, and EXPLAIN and EXPLAIN ANALYZE
> output would help people provide more specific feedback.


Seemed a general enough question that it wasn't necessary.  That, and I
wanted to figure out as much of it on my own as I could, rather than just
get the end-result of an expert's answer without all the knowledge of the
leg work.

Thank you, though.

On Tue, Feb 15, 2011 at 10:20 AM, Vick Khera <vi...@khera.org> wrote:

> On Tue, Feb 15, 2011 at 10:00 AM, Derrick Rice <derrick.r...@gmail.com>
> wrote:
> > Is the query optimizer capable of using the relationship between an index
> on
> > date_trunc(foo) and a query with "where foo < bar and foo > baz" ?  At
> this
> > point the question is to satisfy my own curiosity.
>
> No. The query has to use the same function as the index does.
>

Well that settles it, then.  Thanks, Vick.


>
> I also don't think that the storage space will be any less.  A
> timestamp is always stored in the same amount of space. All you're
> doing is zeroing out the higher resolution bits of time.
>
>
It's been a while since I was intimate with the implementation of a btree.
I was guessing that it might make the tree more "dense" if there were more
values that were equal.  A "dense" tree would be easier to scan when
grabbing all of the children of a particular node (which is the case when
doing a wide range comparison).

The little bit of review that I was able to do reminded me that equal or
unequal values don't make a tree more or less "dense".  It could arguably
make inserts easier (because there's more acceptable places to put an item)
but each node will have n to m items regardless of their relationship to
each other.

On that topic... are the details of PostgreSQL's b-tree implementation found
anywhere outside of the code?  i.e. what n,m-tree values it uses?  Searched
docs and wiki with no luck.

Having fun relearning this stuff

Derrick

Reply via email to