On Fri, 2007-03-09 at 11:39, Axel Rau wrote:
> Am 09.03.2007 um 12:42 schrieb Richard Huxton:
>
> > Axel Rau wrote:
> >> Hi performers,
> >> after following this list for a while, I try to configure a
> >> database server with a limited budget.
> >> Planned are 2 databases
> >> - archiveopteryx
Am 09.03.2007 um 12:42 schrieb Richard Huxton:
Axel Rau wrote:
Hi performers,
after following this list for a while, I try to configure a
database server with a limited budget.
Planned are 2 databases
- archiveopteryx - http://www.archiveopteryx.org/sql-schema.html
- ERDB - https://www.cha
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...
Well, I trie
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 annoying for some of us.
--
Alvaro Herrera
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 su
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_freqs.
n_distinct is -0.359322 an
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
thanks for your replying
>>I think with packing he was referring to simply having more values in
>>the same disk space by using int2 instead of int4. (half the storage space)
I see yes, the values I'm dealing with are a bit too large to do that but yes
good technique. Were they smaller I would
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_
Axel Rau wrote:
Hi performers,
after following this list for a while, I try to configure a database
server with a limited budget.
Planned are 2 databases
- archiveopteryx - http://www.archiveopteryx.org/sql-schema.html
- ERDB -
https://www.chaos1.de/svn-public/repos/network-tools/ERDB/trunk/
Am 08.03.2007 um 12:30 schrieb Axel Rau:
Can I expect similar performance as 5 drives at 10k rpm (same costs)?
Should I revert to a single-CPU to prevent from oscillating cache
updates between CPUS?
Anybody experience about NUMA stuff with FreeBSD?
Do you have any suggestions to enhance the
Hi Tom,
Thanks for the suggestion. It's been a while since I replied to this as I
had to go and do some further investigation of the docs with regards the
autovacuum daemons configuration. According to the documentation, the
formula's for the vacuum and analyze are as follows:
Vacuum
vacuu
19 matches
Mail list logo
