On Fri, Jan 12, 2007 at 07:40:25PM -0500, Dave Cramer wrote:
> 5000 is pretty low, you need at least 1/4 of memory for an 8.1.x or
> newer server.
Is this the new "common wisdom"? It looks like at some point, someone here
said "oh, and it looks like you're better off using large values here for
On 12-Jan-07, at 7:31 PM, Mark Dobbrow wrote:
Hello -
I have a fairly large table (3 million records), and am fetching
10,000 non-contigous records doing a simple select on an indexed
column ie
select grades from large_table where teacher_id = X
This is a test database, so the number of
Hello -
I have a fairly large table (3 million records), and am fetching 10,000
non-contigous records doing a simple select on an indexed column ie
select grades from large_table where teacher_id = X
This is a test database, so the number of records is always 10,000 and i have
300 different
On Thu, 2007-01-11 at 15:01 -0600, Jim C. Nasby wrote:
> I'm wondering if you see any issues with COPYing into a partitioned
> table that's using triggers instead of rules to direct data to the
> appropriate tables?
The data demographics usually guides you towards what to do.
You could COPY into
Yes, casting the result improved the time response a lot.
Thank you!
Reimer
> -Mensagem original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] nome de Tom Lane
> Enviada em: quinta-feira, 11 de janeiro de 2007 16:31
> Para: [EMAIL PROTECTED]
> Cc: pgsql-performance@postgresql.or
Can anybody help me out
I just wanted to knw what will be the configuraion settings for partitioning
table so as to make inserts faster on the partitioned tables.
--
Regards
Gauri
Tobias Brox wrote:
[Heikki Linnakangas - Fri at 10:41:34AM +]
I thought about partitioning the table by state, putting rows with
state=4 into one partition, and all others to another partition.
That sounds like a good idea - but wouldn't that be costly when changing state?
In PostgreSQL,
[Heikki Linnakangas - Fri at 10:41:34AM +]
> I thought about partitioning the table by state, putting rows with
> state=4 into one partition, and all others to another partition.
That sounds like a good idea - but wouldn't that be costly when changing state?
---(end o
Tobias Brox wrote:
Maybe it would help to partitionate the table every year?
I thought about partitioning the table by state, putting rows with
state=4 into one partition, and all others to another partition.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
[Richard Huxton - Fri at 09:17:48AM +]
> Try a partial index:
> CREATE INDEX my_new_index ON events (event_time)
> WHERE state in (1,2,3);
I have that, the index is used and the query is lightning fast - the
only problem is that the planner is using the wrong estimates. This
becomes a real pr
Tobias Brox wrote:
[Peter Childs - Fri at 08:56:54AM +]
Can you say what state might be rather than what it is not. I'm guess
that state is an int but there is only a limited list of possible
states, if you can say what it might be rather than what it is the
index is more liklly to be used.
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a "temp pg_class" which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just needs to be
somewhere from where we can loa
[Peter Childs - Fri at 08:56:54AM +]
> Can you say what state might be rather than what it is not. I'm guess
> that state is an int but there is only a limited list of possible
> states, if you can say what it might be rather than what it is the
> index is more liklly to be used.
explain sel
On 12/01/07, Tobias Brox <[EMAIL PROTECTED]> wrote:
We have a table with a timestamp attribute (event_time) and a state flag
which usually changes value around the event_time (it goes to 4). Now
we have more than two years of events in the database, and around 5k of
future events.
It is importa
We have a table with a timestamp attribute (event_time) and a state flag
which usually changes value around the event_time (it goes to 4). Now
we have more than two years of events in the database, and around 5k of
future events.
It is important to frequently pick out "overdue events", say:
se
15 matches
Mail list logo
