Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Data Bases > Pgsql Performance > Re: large table...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 12 of 15 Topic 3978 of 4424
Post > Topic >>

Re: large tables and simple "= constant" queries using

by wmoran@[EMAIL PROTECTED] (Bill Moran) Apr 9, 2008 at 05:36 PM

This is a FAQ, it comes up on an almost weekly basis.  Please do a
little Googling on count(*) and PostgreSQL and you'll get all the
explanations and suggestions on how to fix the problem you could
ever want.

In response to Arjen van der Meijden <acmmailing@[EMAIL PROTECTED]
>:

> First of all, there is the 'explain analyze' output, which is pretty 
> helpful in postgresql.
> 
> My guess is, postgresql decides to do a table scan for some reason. It 
> might not have enough statistics for this particular table or column, to

> make a sound decision. What you can try is to increase the statistics 
> target, which works pretty easy:
> ALTER TABLE gene_prediction_view ALTER gene_ref SET STATISTICS 200;
> 
> Valid ranges are from 1(0?) - 1000, the default is 10, the default on my

> systems is usually 100. For such a large table, I'd go with 200.
> 
> After that, you'll need to re-analyze your table and you can try again.
> 
> Perhaps analyze should try to establish its own best guess to how many 
> samples it should take? The default of 10 is rather limited for large 
> tables.
> 
> Best regards,
> 
> Arjen
> 
> On 9-4-2008 22:58 John Beaver wrote:
> > Hi, I've started my first project with Postgres (after several years
of 
> > using Mysql), and I'm having an odd performance problem that I was 
> > hoping someone might be able to explain the cause of.
> > 
> > ----My query----
> >    - select count(*) from gene_prediction_view where gene_ref = 523
> >    - takes 26 seconds to execute, and returns 2400 (out of a total of
15 
> > million records in the table)
> > 
> > ---My problem---
> >    Using a single-column index to count 2400 records which are exactly

> > one constant value doesn't sound like something that would take 26 
> > seconds. What's the slowdown? Any silver bullets that might fix this?
> > 
> > ----Steps I've taken----
> >    - I ran vacuum and analyze
> >    - I upped the shared_buffers to 58384, and I upped some of the
other 
> > postgresql.conf values as well. Nothing seemed to help significantly, 
> > but maybe I missed something that would help specifically for this
query 
> > type?
> >    - I tried to create a hash index, but gave up after more than 4
hours 
> > of waiting for it to finish indexing
> > 
> > ----Table stats----
> >    - 15 million rows; I'm expecting to have four or five times this 
> > number eventually.
> >    - 1.5 gigs of hard drive usage
> > 
> > ----My development environment---
> >    - 2.6ghz dual-core MacBook Pro with 4 gigs of ram and a 7200 rpm
hard 
> > drive
> >    - OS X 10.5.2
> >    - Postgres 8.3 (installed via Mac****ts)
> > 
> > ----My table----
> > 
> > CREATE TABLE gene_prediction_view
> > (
> >  id serial NOT NULL,
> >  gene_ref integer NOT NULL,
> >  go_id integer NOT NULL,
> >  go_description character varying(200) NOT NULL,
> >  go_category character varying(50) NOT NULL,
> >  function_verified_exactly boolean NOT NULL,
> >  function_verified_with_parent_go boolean NOT NULL,
> >  function_verified_with_child_go boolean NOT NULL,
> >  score numeric(10,2) NOT NULL,
> >  precision_score numeric(10,2) NOT NULL,
> >  CONSTRAINT gene_prediction_view_pkey PRIMARY KEY (id),
> >  CONSTRAINT gene_prediction_view_gene_ref_fkey FOREIGN KEY (gene_ref)
> >      REFERENCES sgd_annotations (id) MATCH SIMPLE
> >      ON UPDATE NO ACTION ON DELETE NO ACTION,
> >  CONSTRAINT gene_prediction_view_go_id_fkey FOREIGN KEY (go_id)
> >      REFERENCES go_terms (term) MATCH SIMPLE
> >      ON UPDATE NO ACTION ON DELETE NO ACTION,
> >  CONSTRAINT gene_prediction_view_gene_ref_key UNIQUE (gene_ref, go_id)
> > )
> > WITH (OIDS=FALSE);
> > ALTER TABLE gene_prediction_view OWNER TO postgres;
> > 
> > CREATE INDEX ix_gene_prediction_view_gene_ref
> >  ON gene_prediction_view
> >  USING btree
> >  (gene_ref);
> > 
> > 
> > 
> > 
> 
> -- 
> Sent via pgsql-performance mailing list
(pgsql-performance@[EMAIL PROTECTED]
)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance


-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@[EMAIL PROTECTED]
 412-422-3463x4023

****************************************************************
IM****TANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************

-- 
Sent via pgsql-performance mailing list (pgsql-performance@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
 




 15 Posts in Topic:
large tables and simple "= constant" queries using indexes
john.e.beaver@[EMAIL PROT  2008-04-09 16:58:27 
Re: large tables and simple "= constant" queries using
acmmailing@[EMAIL PROTECT  2008-04-09 23:21:20 
Re: large tables and simple "= constant" queries using
acmmailing@[EMAIL PROTECT  2008-04-10 09:13:39 
Re: large tables and simple "= constant" queries using indexes
lists@[EMAIL PROTECTED]   2008-04-10 10:25:48 
Re: large tables and simple "= constant" queries using
matthew@[EMAIL PROTECTED]  2008-04-10 10:51:13 
Re: large tables and simple "= constant" queries using
john.e.beaver@[EMAIL PROT  2008-04-10 10:44:59 
Re: large tables and simple "= constant" queries using indexes
erik@[EMAIL PROTECTED] (  2008-04-10 10:02:48 
Re: large tables and simple "= constant" queries using indexes
Gaetano Mendola <mendo  2008-04-10 18:18:15 
Re: large tables and simple "= constant" queries using indexes
john.e.beaver@[EMAIL PROT  2008-04-10 12:37:45 
Re: large tables and simple "= constant" queries using indexes
lists@[EMAIL PROTECTED]   2008-04-10 23:37:50 
Re: large tables and simple "= constant" queries using
gsmith@[EMAIL PROTECTED]   2008-04-10 14:47:59 
Re: large tables and simple "= constant" queries using
wmoran@[EMAIL PROTECTED]   2008-04-09 17:36:09 
Re: large tables and simple "= constant" queries using
jgh@[EMAIL PROTECTED] (J  2008-04-09 23:07:50 
Re: large tables and simple "= constant" queries using indexes
lists@[EMAIL PROTECTED]   2008-04-10 00:31:00 
Re: large tables and simple "= constant" queries using
wmoran@[EMAIL PROTECTED]   2008-04-10 13:08:54 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Mon Dec 1 7:58:07 CST 2008.