Re: index speed-up and automatic tables/procedures creation

Tom Lane a écrit :
...

> I think you're wasting your time.  What you are setting out to do here
> is manually emulate the top layer or so of a large index.  Unless you
> have very specific (and unusual) data access patterns that you know in
> considerable detail, this is not a game you are going to win.  Just go
> with the one big table and one index, you'll be happier.  (Note that
> "several million rows" is not big, it's barely enough to notice.)
>
> You will see a lot of discussion about partitioning of tables if you
> look around the list archives, but this is not done with the idea that
> it makes access to any one row faster.  The biggest motivation usually
> is to allow dropping ranges of data cheaply, like throwing away a month's
> or year's worth of old data at once.

Just to make sure I understood the spirit:

* I keep a large table,

* As my join tables have just (pkey=pkeys from each side), I also make indexes
   on each foreign pkey,

* (May be?) I also make partial indexes, in order to have ie a faster retrieve
   of not-sold items instead of excluding sold items in the query

JY
--
-- I have seen the FUN --