Re: [PERFORM] statistics target for columns in unique constraint?

2013-05-20 Thread Kevin Grittner
ach 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 just a random sampli

Re: [PERFORM] statistics target for columns in unique constraint?

2013-05-18 Thread ach
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 h

Re: [PERFORM] statistics target for columns in unique constraint?

2013-05-13 Thread Mark Kirkwood
On 14/05/13 10:10, Marti Raudsepp wrote: On Mon, May 13, 2013 at 6:01 PM, ach 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-matchin

Re: [PERFORM] statistics target for columns in unique constraint?

2013-05-13 Thread Marti Raudsepp
On Mon, May 13, 2013 at 6:01 PM, ach 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 constraints/indexes for a qu

Re: [PERFORM] Statistics and Multi-Column indexes

2011-07-15 Thread lars
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 #5

Re: [PERFORM] Statistics and Multi-Column indexes

2011-07-11 Thread Kevin Grittner
lars 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. > > There appea

Re: [PERFORM] Statistics and Multi-Column indexes

2011-07-10 Thread Samuel Gendler
On Sun, Jul 10, 2011 at 2:16 PM, lars 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 columns are only rea

Re: [PERFORM] Statistics use with functions

2009-05-08 Thread Tom Lane
Matthew Wakeling 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 functional indexes

Re: [PERFORM] Statistics use with functions

2009-05-08 Thread Matthew Wakeling
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 the

Re: [PERFORM] Statistics use with functions

2009-05-08 Thread Tom Lane
Matthew Wakeling 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 assume anything abo

Re: [PERFORM] Statistics issue

2008-05-31 Thread Tom Lane
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 <= '2007-

Re: [PERFORM] statistics buffer is full

2006-04-02 Thread Qingqing Zhou
""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 i

Re: [PERFORM] Statistics not working??

2005-03-11 Thread Oleg Bartunov
On Fri, 11 Mar 2005, Hugo Ferreira wrote: Hi there! I think I may have a problem with the statistics in my postgresql 8.0 running under Windowx XP. When I view both pg_stat_all_tables and pg_stat_all_indexes, all the numeric columns that should hold the statistics are 0 (zero). My configuration fil

Re: [PERFORM] statistics

2004-04-08 Thread Jaime Casanova
Thanks for the answer. I know the question was to primitive (it claims: i have no idea about databases). But i simply didn't find the answer and if a don't ask i won't learn. Someday i will talk with Tom Lane about how to improve the planner but until that day comes i have a lot of technical th

Re: [PERFORM] statistics

2004-04-07 Thread Paul Thomas
On 07/04/2004 22:05 Jaime Casanova wrote: What the statistics are? Where can i view it? where can i find info about its field and why are they valuable information to performance? thanx in advance, Jaime Casanova OK. An idiot's guide to statistics by a full-time idiot... Let's start with a si