Mezei Zoltán wrote:
Richard Huxton wrote:
There is a cost to increasing the stats values, otherwise it'd
already be set at 1000. In your case I'm not sure if 100-200 vs 8-9
messages is enough to skew things. Only one way to find out...
Well, I tried. The situation is:
- when I look for a sub
Mezei Zoltán wrote:
Alvaro Herrera wrote:
Would you mind instructing your mail system to skip converting your
text/plain messages to HTML? It's kind of annoying for some of us.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Sorry about that - is this message OK now?
T
Alvaro Herrera wrote:
Would you mind instructing your mail system to skip converting your
text/plain messages to HTML? It's kind of annoying for some of us.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Sorry about that - is this message OK now?
Zizi
-
Title: Re: [PERFORM] Deceiding which index to use
Richard Huxton wrote:
There is a cost to increasing the stats values,
otherwise it'd already
be set at 1000. In your case I'm not sure if 100-200 vs 8-9 messages is
enough to skew things. Only one way to find out...
Mezei Zoltán wrote:
>
>
>
>
>
>
> Richard Huxton wrote:
>
>
>
> Re: [PERFORM] Deceiding which index to use
>
Would you mind instructing your mail system to skip converting your
text/plain messages to HTML? It's kind of ann
Mezei Zoltán wrote:
Richard Huxton wrote:
OK - so the next place to look is the distribution of values for
subscriber_id on the output_message_log. Does that have some subscribers
with many rows and lots with hardly any?
Hmm... There are about 1.5k subscribers with 100-200 messages each - all
Title: Re: [PERFORM] Deceiding which index to use
Richard Huxton wrote:
OK - so the next place to look is the distribution
of values for
subscriber_id on the output_message_log. Does that have some subscribers
with many rows and lots with hardly any?
Hmm... There are about 1.5k
Mezei Zoltán wrote:
Richard Huxton wrote:
And does the planner know that?
SELECT * FROM pg_stats WHERE tablename='subscriber' AND attname='anumber';
It's the n_distinct you're interested in, and perhaps most_common_freqs.
n_distinct is -0.359322 and most_common_vals contains about 10 different
Title: Re: [PERFORM] Deceiding which index to use
Richard Huxton wrote:
And does the planner know that?
SELECT * FROM pg_stats WHERE tablename='subscriber' AND
attname='anumber';
It's the n_distinct you're interested in, and perhaps most_common_freq
Mezei Zoltán wrote:
Richard Huxton wrote:
> Mezei Zoltán wrote:
> Q1. Why are you storing a numeric in a varchar?
Because it's not always numeric info. :/
> Q2. How many unique values does anumber have? And how many rows in
> subscriber?
About 10k distinct anumbers and 20k rows. Nothing sp
Richard Huxton wrote:
> Mezei Zoltán wrote:
> Q1. Why are you storing a numeric in a varchar?
Because it's not always numeric info. :/
> Q2. How many unique values does anumber have? And how many rows in
> subscriber?
About 10k distinct anumbers and 20k rows. Nothing special...
> Q3. What h
Mezei Zoltán wrote:
Hi!
I have two tables with some indices on them:
CREATE TABLE subscriber
(
id serial NOT NULL,
anumber character varying(32) NOT NULL,
CONSTRAINT subscriber_pk PRIMARY KEY (id)
)
CREATE INDEX anumber_idx_numeric
ON subscriber
USING btree
(anumber::numeric);
I
Hi!
I have two tables with some indices on them:
CREATE TABLE subscriber
(
id serial NOT NULL,
anumber character varying(32) NOT NULL,
CONSTRAINT subscriber_pk PRIMARY KEY (id)
)
CREATE INDEX anumber_idx_numeric
ON subscriber
USING btree
(anumber::numeric);
CREATE TABLE output_
13 matches
Mail list logo
