ach alanchi...@gmail.com wrote:
One quick follow up since I'm expecting y'all might know: Do the
statistics targets actually speed performance on an index search
itself; the actual lookup? Or are the JUST to inform the planner
towards the best pathway decision?
Since the statistics are
Thanks guys! I'm gonna try tuning the statistics back down to 10 on that
table and see what that does to the insertion rates. Oh and for Mark: Not
to worry - i'd actually tuned the stats there up myself awhile ago in an
experiment to see if -that- would've sped insertions some; back before i'd
On Mon, May 13, 2013 at 6:01 PM, ach alanchi...@gmail.com wrote:
what I'm wondering is, since
the unique constraint already covers the whole table and all rows in
entirety, is it really necessary for statistics to be set that high on
those?
AFAIK if there are exact-matching unique
On 14/05/13 10:10, Marti Raudsepp wrote:
On Mon, May 13, 2013 at 6:01 PM, ach alanchi...@gmail.com wrote:
what I'm wondering is, since
the unique constraint already covers the whole table and all rows in
entirety, is it really necessary for statistics to be set that high on
those?
AFAIK if
On 07/10/2011 02:31 PM, Samuel Gendler wrote:
What about partitioning tables by tenant id and then maintaining
indexes on each partition independent of tenant id, since constraint
exclusion should handle filtering by tenant id for you. That seems
like a potentially more tolerable variant of
lars lhofha...@yahoo.com wrote:
We are maintaining a large multi tenant database where *all*
tables have a tenant-id and all indexes and PKs lead with the
tenant-id. Statistics and counts for the all other columns are
only really meaningful within the context of the tenant they
belong to.
On Sun, Jul 10, 2011 at 2:16 PM, lars lhofha...@yahoo.com wrote:
I know this has been discussed various times...
We are maintaining a large multi tenant database where *all* tables have a
tenant-id and all indexes and PKs lead with the tenant-id.
Statistics and counts for the all other
Matthew Wakeling matt...@flymine.org writes:
When I wrap the fields in the constraints in a LOWER() function, the
planner stops looking at the statistics and makes a wild guess, even
though it is very obvious from just looking what the result should be.
Well, in general the planner can't
Matthew Wakeling matt...@flymine.org writes:
Ah, now I see it - I re-analysed, and found entries in pg_stats where
tablename is the name of the index. Now the query plans correctly and has
the right estimates. So, one needs to analyse AFTER creating indexes -
didn't know that.
Yes, for
On Fri, 8 May 2009, Tom Lane wrote:
In this case, however, you evidently have an index on lower(distance)
which should have caused ANALYZE to gather stats on the values of that
functional expression. It looks like there might be something wrong
there --- can you look into pg_stats and see if
Vlad Arkhipov [EMAIL PROTECTED] writes:
EXPLAIN ANALYZE
SELECT *
FROM i
WHERE d BETWEEN '2007-05-12' AND '2007-05-12'
Index Scan using i_d on i (cost=0.00..2.39 rows=1 width=402) (actual
time=0.053..4.284 rows=1721 loops=1)
Index Cond: ((d = '2007-05-12'::date) AND (d =
Gábriel Ákos [EMAIL PROTECTED] wrote
I've got this message while heavily inserting into a database. What should
I tune and how? It is postgresql 8.1.3.
2006-03-29 14:16:57.513 CEST:LOG: statistics buffer is full
Since your server is in a heavy load, so the common trick is to increase
12 matches
Mail list logo
