-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We have two tables, dst_port_hour and dst_port_day, which should be
very similar, they both have about 50.000.000 rows. In both tables we
have an index for period_id.
We run postgresql 7.4.5 on a dedicated Debian server, with dual Intel
Xeon 3G
Iain wrote:
I'm hoping I'll have the opportunity to build a similar machine soon and
am wondering about the choice of 64 bit distributions.
Gentoo is obviously a possibility but I'm also condsidering Debian.
There is also a 64 compile of redhat sources somewhere around, but I
can't remember wha
Em Qui, 2004-11-04 às 20:58, Rod Taylor escreveu:
> All 3 plans have crappy estimates.
>
> Run ANALYZE in production, then send another explain analyze (as an
> attachment please, to avoid linewrap).
First of all, I'd like to apoligize for taking so long to post a new
position. After this, I apolo
On Mon, 8 Nov 2004 09:40 pm, Andreas Ãkre Solberg wrote:
> We have two tables, dst_port_hour and dst_port_day, which should be
> very similar, they both have about 50.000.000 rows. In both tables we
> have an index for period_id.
>
> We run postgresql 7.4.5 on a dedicated Debian server, with dual
The ext3fs allows to selet type of journalling to be used with
filesystem. Journalling pretty much "mirrors" the work of WAL
logging by PostgreSQL... I wonder which type of journalling
is best for PgSQL in terms of performance.
Choices include:
journal
All data
> > Good, I'll give it a shot and see what I come up with...thx.
> >
> Do share your experience with us.
Will do. I have to ship the server on Friday, and the parts are on
order. If they come today, I'll have time to test Gentoo, Redhat 32/64,
and win32 by then. If I can't get it built until to
Dawid Kuroczko wrote:
> The ext3fs allows to selet type of journalling to be used with
> filesystem. Journalling pretty much "mirrors" the work of WAL
> logging by PostgreSQL... I wonder which type of journalling
> is best for PgSQL in terms of performance.
> Choices include:
> jour
> Am I right to assume that "writeback" is both fastest and at
> the same time as safe to use as ordered? Maybe any of you
> did some benchmarks?
It should be fastest because it is the least overhead, and safe because
postgres does it's own write-order guaranteeing through fsync(). You should
I have some data here, no detailed analyses though:
http://www.osdl.org/projects/dbt2dev/results/fs/
Mark
On Mon, Nov 08, 2004 at 01:26:09PM +0100, Dawid Kuroczko wrote:
> The ext3fs allows to selet type of journalling to be used with
> filesystem. Journalling pretty much "mirrors" the
Matt,
> It should be fastest because it is the least overhead, and safe because
> postgres does it's own write-order guaranteeing through fsync(). You
> should also mount the FS with the 'noatime' option.
This, of course, assumes that PostgreSQL is the only thing on the partition.
Which is a g
Gabriele,
> I have been given a dual PIII with 768MB RAM and I am going to install
> PostgreSQL on it, for data warehousing reasons. I have also been given four
> 160 Ultra SCSI disks (36MB each) with a RAID controller (Adaptec 2100). I
> am going to use a RAID5 architecture (this gives me app
Sorry for the late reply. Was feeling a bit under the weather
this weekend and didn't get a chance to look at this.
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> patrick ~ <[EMAIL PROTECTED]> writes:
> > PREPARE pkk_00 ( integer ) )
>
> This is what you want to do, but not quite like that. The
patrick ~ wrote:
[...]
pkk=# explain analyze execute pkk_01(241 );
QUERY PLAN
-
Result (cost=2.
This is one of the queries that work,and is the first
in a 4 level nested query
where do I find how to interpret explains???
thanks in advance,
Carlos.
mate=# explain analyze select * from vdocinvdpre;
Hi John,
Thanks for your reply and analysis.
--- John Meinel <[EMAIL PROTECTED]> wrote:
> patrick ~ wrote:
> [...]
> > pkk=# explain analyze execute pkk_01(241 );
> > QUERY PLAN
> >
>
-
Carlos Lopez <[EMAIL PROTECTED]> writes:
> This is one of the queries that work,and is the first
> in a 4 level nested query
Do you really need UNION (as opposed to UNION ALL) in this query?
The EXPLAIN shows that almost half the runtime is going into the
sort/uniq to eliminate duplicates ...
patrick ~ wrote:
Hi John,
Thanks for your reply and analysis.
No problem. It just happens that this is a problem we ran into recently.
--- John Meinel <[EMAIL PROTECTED]> wrote:
patrick ~ wrote:
[...]
Hmm... The fact is I am selecting (in this example anyway) over all
values in pkk_offer table and
Lets say for a second that you manage to trick it into using index scan,
and then you actually call the function with one of the values that
returns 1,000s of rows. Probably it will take 10-100 times longer than
if it used a seq scan.
I don't know if it matters (I suspect that it does) but I am u
Greetings all,
This question has probably been asked many times, but I was unable to
use the list archives to search, since the term "Group" matches
thousands of of messages with the names of user groups in them... so
sorry if I'm repeating!
Here's the problem: I have a table of 10,000,000
patrick ~ wrote:
Hi John,
Thanks for your reply and analysis.
--- John Meinel <[EMAIL PROTECTED]> wrote:
patrick ~ wrote:
[...]
pkk=# explain analyze execute pkk_01(241 );
QUERY PLAN
One other thing that I just thought of. I think it is actually possible
to add an index on a function of
Erik Norvelle <[EMAIL PROTECTED]> writes:
>>> it=> explain select codelemm, sectref, count(codelemm) from indethom
> group by codelemm, sectref;
>>> QUERY PLAN
>>> ---
> -
>>> GroupAggregate (cost=2339900.60..2444149.44
Gabriele,
> By any chance, do you have some reference or some tests that talk about the
> fact that RAID5 with less than 5 disks is not performing?
Just this list. But it's easy to test yourself; run bonnie++ and compare the
performance of seeks and random writes (which PG does a lot of) vs. a
22 matches
Mail list logo
