Re: Fast insertion indexes: why no developments - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Fast insertion indexes: why no developments
Date
Msg-id CA+U5nM+w6MayL3hWNEAg+h=yMq6XfcagB6tw21nbxbcV0hPBgA@mail.gmail.com
Whole thread Raw
In response to Re: Fast insertion indexes: why no developments  (Leonardo Francalanci <m_lists@yahoo.it>)
Responses Re: Fast insertion indexes: why no developments  (Leonardo Francalanci <m_lists@yahoo.it>)
List pgsql-hackers
On 5 November 2013 09:57, Leonardo Francalanci <m_lists@yahoo.it> wrote:
> Simon Riggs wrote
>> Minmax indexes seem to surprise many people, so broad generalisations
>> aren't likely to be useful.
>>
>> I think the best thing to do is to publish some SQL requests that
>> demonstrate in detail what you are trying to achieve and test them
>> against minmax indexes. That way we can discuss what does work and
>> what doesn't work well enough yet.
>
> While I do believe in testing (since "In theory there is no difference
> between theory and practice. In practice there is"), I would like to know
> the "properties" of the minmax index before trying it.
> What is it supposed to be good at? What are the pros/cons? We can't ask all
> the users to just "try" the index and see if it works for them.

No, but then all users aren't suggesting we need a new index type are they?

I think its reasonable for you to spend time checking whether what you
require will be met, and if not, what precise query doesn't it help,
so we can better design any future new-index.

> As I said, my understanding is that is very efficient (both in insertion and
> in searching) when data is somehow ordered in the table. But maybe I got it
> wrong...

> Anyway, the sql scenario is simple: a table with 4 bigint indexes; data in
> the fields is a random bigint in the range 1-10000000. Insertion is 5-10K
> rows/second. One search every 1-5 seconds, by one of the indexed fields
> (only equality, no range). There's also an index on a timestamp field, but
> that's not random so it doesn't give that many problems (it's actually the
> one where I wanted to try the minmax).

Without meaning to pick on you, imprecise analysis yields unhelpful
new features. The clearer we are about what we are trying to solve the
more likely we are to solve it well. 30 seconds analysis on what is
needed is not sufficient to justify an additional man year of
development, especially if a man year of work has already been done
and the testing of the latest feature is now at hand.

The requests from the indexes field, are they ordered? are they
limited? Or you really want ALL calls? What is the tolerance on those?

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Oskari Saarenmaa
Date:
Subject: [PATCH] configure: add git describe output to PG_VERSION when building a git tree
Next
From: Leonardo Francalanci
Date:
Subject: Re: Fast insertion indexes: why no developments