Hi everyone,
I have done some reading on filesystems and I thought to optimize the
settings for my PostgreSQL system. I use the ext3 filesystem and have the
PostgreSQL data and WAL on different physical drives. I made some
adjustments to my /etc/fstabd file, so it looks like this :
LABEL=/
On Thu, 2004-04-08 at 14:13, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But it should be okay to set the filesystem to journal only its own
> >> metadata. There's no need for it to journal file contents.
>
> > Can you set ext2 to journal metadata? I didn
> LABEL=/usr/local/pgsql /usr/local/pgsql ext3
> noatime,data=writeback 1 2
> LABEL=/usr/local/pgsql /usr/local/pgsql/wal ext3
> noatime,data=ordered1 2
The same label mounted on two different mount points is probably I typo?
I'm not sure if data=writeback is ok. I was wondering abou
> > > LABEL=/usr/local/pgsql /usr/local/pgsql ext3
> > > noatime,data=writeback 1 2
> > > LABEL=/usr/local/pgsql /usr/local/pgsql/wal ext3
> > > noatime,data=ordered1 2
> >
> > The same label mounted on two different mount points is probably I typo?
>
>
> No, the same label mounted
Hello,
I've followed the last discussion about the particular case of
"select count(*)"s on large tables being somewhat slow.
I've seen also this issue already on the todo list, so I know
it is not a simple question.
This problem arises for me on very large tables, which I mean
starting from 1 mil
> > > > LABEL=/usr/local/pgsql /usr/local/pgsql ext3
> > > > noatime,data=writeback 1 2
> > > > LABEL=/usr/local/pgsql /usr/local/pgsql/wal ext3
> > > > noatime,data=ordered1 2
> > >
> > > The same label mounted on two different mount points is probably I
> > > typo?
> >
> >
> > No,
> > LABEL=/usr/local/pgsql /usr/local/pgsql ext3
> > noatime,data=writeback 1 2
> > LABEL=/usr/local/pgsql /usr/local/pgsql/wal ext3
> > noatime,data=ordered1 2
>
> The same label mounted on two different mount points is probably I typo?
No, the same label mounted on two different mo
On Thu, 8 Apr 2004, Cosimo Streppone wrote:
> The alternative solution I tried, that has an optimal
> speed up, unfortunately is not a way out, and it is based
> on "EXPLAIN SELECT count(*)" output parsing, which
> is obviously *not* reliable.
Try this to get the estimate:
SELECT relname, rel
Andrew McMillan wrote:
On Thu, 2004-04-08 at 14:13, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
But it should be okay to set the filesystem to journal only its
own metadata. There's no need for it to journal file contents.
Can you set ext2 to journal metadata? I
> When I give "mount" at the command line, everything looks just fine :
>
> /dev/sda2 on / type ext3 (rw,noatime,data=ordered)
> none on /proc type proc (rw)
> usbdevfs on /proc/bus/usb type usbdevfs (rw)
> /dev/sda1 on /boot type ext3 (rw,noatime,data=ordered)
> none on /dev/pts type devpts (rw,gi
Cosimo Streppone <[EMAIL PROTECTED]> writes:
> Is there an estimate time for this issue to be resolved?
Approximately never. It's a fundamental feature of Postgres' design.
As noted by Dennis, you can look at the pg_class statistics if a recent
estimate is good enough, or you can build user-leve
Andrew McMillan wrote:
> On Thu, 2004-04-08 at 14:13, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> But it should be okay to set the filesystem to journal only its own
> > >> metadata. There's no need for it to journal file contents.
> >
> > > Can you
[EMAIL PROTECTED] wrote:
> > When I give "mount" at the command line, everything looks just fine :
> >
> > /dev/sda2 on / type ext3 (rw,noatime,data=ordered)
> > none on /proc type proc (rw)
> > usbdevfs on /proc/bus/usb type usbdevfs (rw)
> > /dev/sda1 on /boot type ext3 (rw,noatime,data=ordered)
On Wed, 2004-04-07 at 16:27, scott.marlowe wrote:
> On Wed, 7 Apr 2004, Nid wrote:
>
> > Rather than ask some general, unanswerable question on how to tune my
> > database...I thought I ask where I might find an introduction to...or
> > manual/tutorial for the depths of managing a postgres db.
Hello,
I've just started using the tsearch2 system. I'm VERY impressed by the
speed.
I've got one question about query planning. Is it understandable to
have the query plan estimation be off by a couple of orders of
magnitude? Or, is it the fact that the cost estimation is small to
beg
Thanks for the answer.
I know the question was to primitive (it claims: i have no idea about
databases).
But i simply didn't find the answer and if a don't ask i won't learn.
Someday i will talk with Tom Lane about how to improve the planner but until
that day comes i have a lot of technical th
Mark,
> I've got one question about query planning. Is it understandable to
> have the query plan estimation be off by a couple of orders of
> magnitude? Or, is it the fact that the cost estimation is small to
> begin with that the error between the actual and the estimated is
> "normal"
On Apr 8, 2004, at 6:33 PM, Josh Berkus wrote:
Mark,
I've got one question about query planning. Is it understandable to
have the query plan estimation be off by a couple of orders of
magnitude? Or, is it the fact that the cost estimation is small to
begin with that the error between the actual
Mark Lubratt <[EMAIL PROTECTED]> writes:
> I guess I was looking more at the cost estimate and not so much at the
> rows estimate. I agree that the row estimate wasn't too bad. But the
> cost estimate seems way out of line.
The cost estimates are not even in the same units as the actual runtim
19 matches
Mail list logo
