Hi,
I've been working on trying to partition a big table (I've never partitioned a
table in any other database till now).
Everything went ok, except one query that didn't work afterwards.
I've put the partition description, indexes, etc ..., and the explain plan
attached.
The query is
Did you set constraint_exclusion = true in postgresql.conf file?
On 12/13/05, Marc Cousin [EMAIL PROTECTED] wrote:
Hi,
I've been working on trying to partition a big table (I've never partitioned a
table in any other database till now).
Everything went ok, except one query that didn't work
I just saw that there is no where clause in the query, that you had
fed to explain plan.
you need to include a where clause based on id_machine column to see the effect.
On 12/13/05, Pandurangan R S [EMAIL PROTECTED] wrote:
Did you set constraint_exclusion = true in postgresql.conf file?
On
Yes, that's how I solved it... and I totally agree that it's hard for the
planner to guess what to do on the partitions. But maybe there should be
something in the docs explaining the limitations ...
I'm only asking for the biggest 100 ids from the table, so I thought maybe the
planner would
Hi.
create table device(id int);
insert into device values(1);
insert into device values(2);
.
insert into device values(250);
create table base (
id int,
data float,
Ключников А.С. wrote:
And
select * from base
where id in (1,2) and datatime between '2005-05-15' and '2005-05-17';
10 seconds
select * from base
where id in (select id from device where id = 1 or id = 2) and
datatime between '2005-05-15' and '2005-05-17';
10 minits
Why?
Jim C. Nasby writes:
On Fri, Dec 02, 2005 at 06:28:09PM -0500, Francisco Reyes wrote:
I am in the process of designing a new system.
There will be a long list of words such as
-word table
word_id integer
word varchar
special boolean
Some special words are used to determine if some work is to
On Tue, Dec 13, 2005 at 06:18:19PM +0300, Ключников А.С. wrote:
select * from base
where id in (select id from device where id = 1 or id = 2) and
datatime between '2005-05-15' and '2005-05-17';
10 minits
That's a really odd way of saying 1 or 2. It probably has to go through all
* Richard Huxton dev@archonet.com [2005-12-13 15:59:11 +]:
Ключников А.С. wrote:
And
select * from base
where id in (1,2) and datatime between '2005-05-15' and '2005-05-17';
10 seconds
select * from base
where id in (select id from device where id = 1 or id = 2) and
Resending it here as it may be more relevant here...
Ameet
-- Forwarded message --
Date: Tue, 13 Dec 2005 11:24:26 -0600 (CST)
From: Ameet Kini [EMAIL PROTECTED]
To: pgsql-admin@postgresql.org
Subject: Lots of postmaster processes
In our installation of the postgres 7.4.7, we
On Tue, 2005-12-13 at 15:59 +, Richard Huxton wrote:
Ключников А.С. wrote:
And
select * from base
where id in (1,2) and datatime between '2005-05-15' and '2005-05-17';
10 seconds
select * from base
where id in (select id from device where id = 1 or id = 2) and
On Mon, 2005-12-12 at 15:07 +1300, Mike C wrote:
Partitioning on date range doesn't make much sense for this setup,
where a typical 1-month query spans both tables (as the billing month
for the customer might start midway through a calendar month).
Maybe not for queries, but if you use a date
Postgres 8.1 performance rocks (compared with 8.0) specially with the use
in-memory index bitmaps. Complex queries that used to take 30+ minutes, it
takes now a few minutes to complete in 8.1. Many thanks to the all wonderful
developers for the huge 8.1 performance boost.
---
Husam
On Thu, 2005-12-08 at 12:26 +0100, Pål Stenslet wrote:
I'm currently benchmarking several RDBMSs with respect to analytical
query performance on medium-sized multidimensional data sets. The data
set contains 30,000,000 fact rows evenly distributed in a
multidimensional space of 9 hierarchical
On 12/14/05, Simon Riggs [EMAIL PROTECTED] wrote:
Maybe not for queries, but if you use a date range then you never needto run a DELETE and never need to VACUUM.You could split the data into two-day chunks.
That's an interesting idea, thanks.
Am I using a horrid method for partitioning the data?
Simon,
Yes, I'd expect something like this right now in 8.1; the
numbers stack up to PostgreSQL doing equivalent join speeds,
but w/o star join.
I do expect a significant improvement from 8.1 using the new bitmap index
because there is no need to scan the full Btree indexes. Also, the
Hello all,
It seems that I'm starting to outgrow our current Postgres setup. We've been
running a handful of machines as standalone db servers. This is all in a
colocation environment, so everything is stuffed into 1U Supermicro boxes. Our
standard build looks like this:
Supermicro 1U
Charles,
Lastly, one thing that I'm not yet finding in trying to
educate myself on SANs is a good overview of what's come out
in the past few years that's more affordable than the old
big-iron stuff. For example I saw some brief info on this
list's archives about the Dell/EMC offerings.
Charles Sprickman wrote:
Hello all,
It seems that I'm starting to outgrow our current Postgres setup. We've
been running a handful of machines as standalone db servers. This is
all in a colocation environment, so everything is stuffed into 1U
Supermicro boxes. Our standard build looks
19 matches
Mail list logo
