Thx a lot Nicolas,
I finaly success to log query statement because of your simple explanation.
I have other question:
1. Is there posibility to automatically logging that statement to table?
2. All of that statement is come from every database on my server,
could I know from which database that
On Mon, 21 Jul 2008, System/IJS - Joko wrote:
Thx a lot Nicolas,
I finaly success to log query statement because of your simple explanation.
I have other question:
1. Is there posibility to automatically logging that statement to table?
I don't know, never tried that.
2. All of that
Luke Lonergan wrote:
pgbench is unrelated to the workload you are concerned with if ETL/ELT
and decision support / data warehousing queries are your target.
Also - placing the xlog on dedicated disks is mostly irrelevant to
data warehouse / decision support work or ELT. If you need to
Hi Stephane,
On 7/21/08 1:53 AM, Stephane Bailliez [EMAIL PROTECTED] wrote:
I'd suggest RAID5, or even better, configure all eight disks as a JBOD
in the RAID adapter and run ZFS RAIDZ. You would then expect to get
about 7 x 80 = 560 MB/s on your single query.
Do you have a particular
Greg Smith wrote:
Note that I've had some issues with the desktop Ubuntu giving slower
results in tests like this than the same kernel release using the
stock kernel parameters. Haven't had a chance yet to see how the
server Ubuntu kernel fits into that or exactly what the desktop one is
Dear PostgreSQL community,
first some info about our application:
- Online course directory for a University
- Amount of data: complete dump is 27 MB
- Semester is part of primary key in each table
- Data for approx. 10 semesters stored in the DB
- Read-only access from web application (JDBC)
Andreas Hartmann wrote:
Dear PostgreSQL community,
first some info about our application:
- Online course directory for a University
- Amount of data: complete dump is 27 MB
- Semester is part of primary key in each table
- Data for approx. 10 semesters stored in the DB
- Read-only access from
Hi,
I have ran quite a few tests comparing how long a query takes to execute from
Perl/DBI as compared to psql/pqlib. No matter how many times I run the test the
results were always the same.
I run a SELECT all on a fairly big table and enabled the
log_min_duration_statement option. With psql
Richard, thanks for your reply!
Richard Huxton schrieb:
Andreas Hartmann wrote:
Dear PostgreSQL community,
first some info about our application:
- Online course directory for a University
- Amount of data: complete dump is 27 MB
- Semester is part of primary key in each table
- Data for
On Mon, Jul 21, 2008 at 1:25 PM, Andreas Hartmann [EMAIL PROTECTED] wrote:
SELECT pg_database.datname,
pg_size_pretty(pg_database_size(pg_database.datname)) AS size
FROM pg_database where pg_database.datname = 'vvz_live_1';
datname| size
---+-
vvz_live_1|
Andreas Hartmann wrote:
Here's some info about the actual amount of data:
SELECT pg_database.datname,
pg_size_pretty(pg_database_size(pg_database.datname)) AS size
FROM pg_database where pg_database.datname = 'vvz_live_1';
datname| size
---+-
vvz_live_1| 2565
Valentin Bogdanov wrote:
Hi,
I have ran quite a few tests comparing how long a query takes to execute from
Perl/DBI as compared to psql/pqlib. No matter how many times I run the test the
results were always the same.
I run a SELECT all on a fairly big table and enabled the
Guillaume Smet wrote:
On Mon, Jul 21, 2008 at 1:25 PM, Andreas Hartmann [EMAIL PROTECTED] wrote:
SELECT pg_database.datname,
pg_size_pretty(pg_database_size(pg_database.datname)) AS size
FROM pg_database where pg_database.datname = 'vvz_live_1';
datname| size
---+-
On Jul 21, 2008, at 5:19 AM, Valentin Bogdanov wrote:
Hi,
I have ran quite a few tests comparing how long a query takes to
execute from Perl/DBI as compared to psql/pqlib. No matter how many
times I run the test the results were always the same.
I run a SELECT all on a fairly big table
Hi,
Reducing the amount of data will only have effect on table scan or index
scan. If your queries are selective and optimized, it will have no effect.
Before looking for solutions, the first thing to do is to understand what's
happen.
If you already know the queries then explain them.
Valentin Bogdanov wrote:
I have ran quite a few tests comparing how long a query takes to
execute from Perl/DBI as compared to psql/pqlib. No matter how many
times I run the test the results were always the same.
I run a SELECT all on a fairly big table and enabled the
A Dilluns 21 Juliol 2008, Leví Teodoro da Silva va escriure:
Hi Guys,
I am developing a project with PostgreSQL and one guy from project is
familiar with Oracle and did a question for me, but i could not answer, if
someone could help it will be good. =)
The question is :
*
- In oracle he
am Mon, dem 21.07.2008, um 15:20:27 -0300 mailte Leví Teodoro da Silva
folgendes:
- In oracle he makes a full backup two times in a day. In this range of time,
Oracle make a lot of mini-backups, but this backups is about just the data
whose have changed in this time. If the system fails, he
On Mon, 21 Jul 2008, Stephane Bailliez wrote:
Isn't it a scheduler problem, I thought CFQ was the default for desktop
?
CFQ/Deadline/AS are I/O scheduler choices. What changed completely in
2.6.23 is the kernel process scheduler.
Craig James [EMAIL PROTECTED] writes:
Valentin Bogdanov wrote:
I have ran quite a few tests comparing how long a query takes to
execute from Perl/DBI as compared to psql/pqlib. No matter how many
times I run the test the results were always the same.
I run a SELECT all on a fairly big
On Mon, Jul 21, 2008 at 03:20:27PM -0300, Leví Teodoro da Silva wrote:
- In oracle he makes a full backup two times in a day. In this range of
time, Oracle make a lot of mini-backups, but this backups is about just the
data whose have changed in this time. If the system fails, he could
Thank you guys for the fast answer.
This same guy asked me about the support on PostgreSQL. When he see the
community behind PostgreSQL , he never will be worried about support. =)
Thanks a lot,
Leví
A. Kretschmer escreveu:
am Mon, dem 21.07.2008, um 15:20:27 -0300 mailte Leví Teodoro da
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
Sure, but so does psql (unless you've turned on the magic FETCH_COUNT
setting). I think the theories about prepared versus literal statements
were more promising; but I don't know DBI well enough to know exactly
what it was
On 2:59 pm 06/29/08 Greg Smith [EMAIL PROTECTED] wrote:
Right now I'm working with a few other people to put together a more
straightforward single intro guide that should address some of the
vagueness you point out here,
Was that ever completed?
--
Sent via pgsql-performance mailing list
[...]
Yes I'd definitely prefer to go 8.3 as well but there are a couple
reasons for now I have to suck it up:
- 8.2 is the one in the 7.10 repository.
- I need plr as well and 8.3-plr debian package does not exist yet.
(I know in both cases we could recompile and install it from there,
but
--On tisdag, juli 22, 2008 01.20.52 +0200 Emil Pedersen
[EMAIL PROTECTED] wrote:
[...]
Yes I'd definitely prefer to go 8.3 as well but there are a couple
reasons for now I have to suck it up:
- 8.2 is the one in the 7.10 repository.
- I need plr as well and 8.3-plr debian package does
Emil Pedersen [EMAIL PROTECTED] writes:
At least on debian it was quite easy to backport 8.3.3 from sid
to etch using apt-get's source and build-dep functions. That way
you get a normal installable package.
I should have said that I was talking about the postgresql, I
missed the plr part.
27 matches
Mail list logo
