Just have one example here:
workload: run pgbench in 365x24x7
database size: 100GB
the workload distribution:
06:00-24:00 100tps
00:00-06:00 20tps
how should we plan vacuum for this situation to get the highest performance?
Best regards
Galy
Galy Lee wrote:
> Hi,
>
> For I can no
"Dave Dutcher" <[EMAIL PROTECTED]> writes:
> I discovered a query which is taking 70 seconds on 8.2.1 which used to take
> under a second on 8.1.2. I was digging into what was causing it and I
> believe the problem is a view which the planner estimates will return 1 row
> when it actually returns
Hi,
For I can not find too much information about how to use vacuum, I want
to ask some general information about the guideline of vacuum planning.
1. How do we know if autovacuum is enough for my application, or should
I setup a vacuum manually from cron for my application?
2. How to set t
Tobias Brox wrote:
I suppose the strongest argument for introducing date dimensions already
now is that I probably will benefit from having conform and
well-designed dimensions when I will be introducing more data marts. As
for now I have only one fact table and some few dimensions in the
syst
Laurent Manchon wrote:
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
select count(*)from tbl;
PostgreSQL return result in 28 sec every time.
Can you post the results of:
analyze verbose tbl;
explain analyze select count(*) from
Hello,
I discovered a query which is taking 70 seconds on 8.2.1 which used to take
under a second on 8.1.2. I was digging into what was causing it and I
believe the problem is a view which the planner estimates will return 1 row
when it actually returns 3500. When I join with the view, the plann
On Tue, Jan 23, 2007 at 11:34:52 +0100,
Laurent Manchon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
>
> PostgreSQL return result in 28 sec every time.
> although MS-
On 1/23/07, Tobias Brox <[EMAIL PROTECTED]> wrote:
Does anyone have experience with using postgres for data warehousing?
Right, I saw one post suggestion to use mysql for a mostly read-only
database ... but anyway, I think it's not a question to change the
database platform for this project, at l
Hello all,
I have a setup in which four client machines access
a Postgres database (8.1.1) (on a Linux box). So,
there are connections from each machine to the
database; hence, the Linux box has about 2 postgres
processes associated with each machine.
I am using the JDBC driver
(postgresql-8.
At 07:34 AM 1/23/2007, Laurent Manchon wrote:
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
1= Upgrade to the latest stable version of pg. That would be
8.2.x You are very much in the Dark Ages pg version wise.
pg 8.x has sign
In response to Laurent Manchon <[EMAIL PROTECTED]>:
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
>
> PostgreSQL return result in 28 sec every time.
> although MS-SQL return result in 0.02 sec every tim
[Chad Wagner - Tue at 08:24:34AM -0500]
> I guess go with your gut, but at some point the expressions are going to be
> too complicated to maintain, and inefficient.
The layout of my system is quite flexible, so it should eventually be
fairly trivial to throw in a date dimension at a later stage.
On 1/23/07, Tobias Brox <[EMAIL PROTECTED]> wrote:
Ralph Kimball seems to be some kind of guru on data warehousing, and
in his books he's strongly recommending to have a date dimension -
simply a table describing all dates in the system, and having
I would tend to agree with this line of thou
Does anyone have experience with using postgres for data warehousing?
Right, I saw one post suggestion to use mysql for a mostly read-only
database ... but anyway, I think it's not a question to change the
database platform for this project, at least not today ;-)
Ralph Kimball seems to be some ki
am Tue, dem 23.01.2007, um 13:34:19 +0100 mailte Laurent Manchon folgendes:
> Hi,
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
PLEASE READ THE ANSWERS FOR YOUR OTHER MAILS.
Andreas
--
Andreas Krets
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
select count(*)from tbl;
PostgreSQL return result in 28 sec every time.
although MS-SQL return result in 0.02 sec every time.
My server is a DELL PowerEdge 2600 with bi-processor Xeon a
On Tue, Jan 23, 2007 at 11:55:41AM +0100, Steinar H. Gunderson wrote:
> you'll find them to be much master.
s/master/faster/
/* Steinar */
--
Homepage: http://www.sesse.net/
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will i
On Tue, Jan 23, 2007 at 11:34:52AM +0100, Laurent Manchon wrote:
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
Contrary to your expectations, this is _not_ a query you'd expect to be fast
in Postgres. Try
am Tue, dem 23.01.2007, um 11:34:52 +0100 mailte Laurent Manchon folgendes:
> Hi,
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
If i remember correctly, i saw this question yesterday on an other
list..
Am 23.01.2007 um 11:34 schrieb Laurent Manchon:
Hi,
I have a slow response of my PostgreSQL database 7.4 using this
query below
on a table with 80 rows:
select count(*)from tbl;
count(*) is doing a full tablescan over all your 80 rows. This is
a well known "feature"
of postgre
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
select count(*)from tbl;
PostgreSQL return result in 28 sec every time.
although MS-SQL return result in 0.02 sec every time.
My server is a DELL PowerEdge 2600 with bi-processor Xeon a
21 matches
Mail list logo
