Tim Uckun writes:
>> As I've stated repeatedly, your next move needs to be to increase the
>> stats target, at least for that column if not globally.
> Ok How do I go about doing this.
If you want to do it globally for the whole database: change
default_statistics_target in postgresql.conf. If
>
> As I've stated repeatedly, your next move needs to be to increase the
> stats target, at least for that column if not globally. You probably
> don't need to have it know about every last domain id, but you need to
> have it know about enough that it realizes that domains not included in
> the
Tim Uckun writes:
>> Am I right in guessing that pg_stats.n_distinct is much too low for
>> the domain_id column?
> the domain_id is in the topical urls. A select count of domains shows
> that there are 700 domains, the pg_stats shows 170 which seems kind of
> low but maybe is not out of bounds b
> With a table that large, you're probably going to need a larger stats
> target in order to get reasonable estimates for low-frequency values.
> Am I right in guessing that pg_stats.n_distinct is much too low for
> the domain_id column?
the domain_id is in the topical urls. A select count of doma
Tim Uckun writes:
> relname | pg_relation_size | reltuples | relpages
> +--+-+--
> consolidated_urls | 1303060480 | 1.80192e+06 | 159065
> consolidated_urls_pkey |114745344 | 1.80192e+06 |14007
"Karsten Loesing" writes:
> Modifying an array as described in
> http://www.postgresql.org/docs/8.4/static/arrays.html#ARRAYS-MODIFYING
> sometimes leads to uninitialized values. See the following example:
> CREATE TABLE test_array (my_array BIGINT[]);
> INSERT INTO test_array (my_array) VALUES
On Mon, Jan 17, 2011 at 8:23 AM, Tim Uckun wrote:
>> Hmm. What do you get for:
>>
>> SELECT relname, pg_relation_size(oid), reltuples, relpages FROM
>> pg_class WHERE relname IN ('consolidated_urls',
>> 'consolidated_urls_pkey');
>
> relname | pg_relation_size | reltuples | relpa
Excerpts from Alex Hunsaker's message of vie ene 14 03:33:17 -0300 2011:
> On Thu, Jan 13, 2011 at 06:57, Julien Demoor wrote:
> It looks like we are not incrementing a reference count for NULL
> entries in an array. The attached fixes it for me. I did look for
> other places where we might hav
Excerpts from Jeff Turner's message of lun ene 17 07:34:29 -0300 2011:
> test=# select *, rank()+1 over (partition by bar) from t;
> ERROR: syntax error at or near "over"
> LINE 1: select *, rank()+1 over (partition by bar) from t;
The "over" stuff is part of the expression; you can't add the +1
The following bug has been logged online:
Bug reference: 5841
Logged by: Jeff Turner
Email address: j...@biccard.com
PostgreSQL version: 9.0.1
Operating system: Ubuntu 10.10
Description:rank()+1 fails, 1+rank() succeeds
Details:
Given a table:
create table t (foo v
>
> Hmm. What do you get for:
>
> SELECT relname, pg_relation_size(oid), reltuples, relpages FROM
> pg_class WHERE relname IN ('consolidated_urls',
> 'consolidated_urls_pkey');
>
relname | pg_relation_size | reltuples | relpages
+--+-
On Sun, Jan 16, 2011 at 5:47 PM, Tim Uckun wrote:
>> Hmm, autovacuum *should* have been keeping track of things for you,
>> but it might still be worth doing a manual ANALYZE against that table
>> to see if the estimated rowcount changes. If not, you'll need to raise
>> the statistics target for
12 matches
Mail list logo
