Thanks a lot.
Well, if I'm understanding you correctly, then doing the vertical splitting
for some of the text columns WOULD decrease the average row size returned in
my slimmer PRODUCTIONS table. I don't plan on using any of the "prod_info"
columns in a WHERE clause (except open_date and close_da
What you're describing is known as vertical partitioning (think of
splitting a table vertically), and can be a good technique for
increasing performance when used properly. The key is to try and get the
average row size down, since that means more rows per page which means
less I/O. Some things to
On Mon, Oct 10, 2005 at 03:28:42PM -0700, Steve Poe wrote:
I don't have room for more drives, but I am considering moving the XFS
external log
There is absolutely no reason to move the xfs log on a system that
small.
Mike Stone
---(end of broadcast)-
Jon Brisbin <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If you're not swapping then you do not have a problem.
> Except for the fact that my Java App server crashes when all the
> available memory is being used by caching and not reclaimed :-)
That's a kernel bug (or possibly a Java bug ;-)
Fellow Postgresql users,
I have a Pg 7.4.8 data on XFS RAID10 6-disc (U320 SCSI on LSI MegaRAID
w/bbu). The pg_xlog is on its own RAID1 with nothing else.
I don't have room for more drives, but I am considering moving the XFS
external log of the data directory to the RAID1 where the pg_xlog
exist
Jon Brisbin wrote:
> Tom Lane wrote:
> >
> >Are you sure it's not cached data pages, rather than cached inodes?
> >If so, the above behavior is *good*.
> >
> >People often have a mistaken notion that having near-zero free RAM means
> >they have a problem. In point of fact, that is the way it is su
More info:
apps:/home/jbrisbin # free -mo
total used free sharedbufferscached
Mem: 8116 5078 3038 0 92 4330
Swap: 1031 0 1031
apps:/home/jbrisbin # cat /proc/meminfo
MemTotal: 8311188 kB
Tom Lane wrote:
Are you sure it's not cached data pages, rather than cached inodes?
If so, the above behavior is *good*.
People often have a mistaken notion that having near-zero free RAM means
they have a problem. In point of fact, that is the way it is supposed
to be (at least on Unix-like s
Jon,
> Any help you can give in this would be extrememly helpful as I'm very
> far from an expert on Linux filesystems and postgres tuning.
See Tom's response; it may be that you don't have an issue at all.
If you do, it's probably the kernel, not the FS. 2.6.8 and a few other
2.6.single-digit
Jon Brisbin <[EMAIL PROTECTED]> writes:
> I have a SUSE 9 box that is running Postgres 8.0.1 compiled from source.
> Over time, I see the memory usage of the box go way way up (it's got
> 8GBs in it and by the end of the day, it'll be all used up) with what
> looks like cached inodes relating to
> I have a SUSE 9 box that is running Postgres 8.0.1 compiled from source.
> Over time, I see the memory usage of the box go way way up (it's got
> 8GBs in it and by the end of the day, it'll be all used up) with what
> looks like cached inodes relating to the extreme IO generated by
>
> I was wond
I have a SUSE 9 box that is running Postgres 8.0.1 compiled from source.
Over time, I see the memory usage of the box go way way up (it's got
8GBs in it and by the end of the day, it'll be all used up) with what
looks like cached inodes relating to the extreme IO generated by
postgres. We repli
Sorry but this does not seem to improve performance, it takes even more
time, have a look at these data:
explain analyze SELECT * FROM ViewHttp
WHERE (vchost || txcontenttype) ilike '%www.%html%'
ORDER BY iDStart DESC, iSensorID DESC, iForensicID DESC, iSubID DESC
OFFSET 0 LIMIT 201
"Limit
"Federico Simonetti (Liveye)" <[EMAIL PROTECTED]> writes:
> I'm encountering a quite strange performance problem.
The problem stems from the horrid misestimation of the number of rows
fetched from detail0009:
> "-> Seq Scan on detail0009 (cost=0.00..20500.11
> rows=26 width=
Yes you're right it really bosst a little.
I want to improve the system performance. Are there any more tipps?
The rest of the numbers look vaguely ok...
On this server runs only a webserver with php application which uses
postgre Db. Should I give more memory to postgre? From what I noticed
Stef <[EMAIL PROTECTED]> writes:
> I saw that the default storage type for text columns is
> "EXTENDED" which, according to the documentation, uses up extra
> space to make possible substring functioning faster.
You misread it. EXTENDED does compression by default on long strings.
EXTERNAL is th
When I ment memory allocation, I look with htop to see the process list, CPU
load, memory, swap. So I didn't ment the a postgre process uses that amount
of memory.
I read some tuning things, I made the things that are written there, but I
think that there improvements can be made.
regards,
A
"Andy" <[EMAIL PROTECTED]> writes:
> I get the feeling the server is somehow missconfigured or it does not
> work at full parameter. If I look at memory allocation, it never goes
> over 250MB whatever I do with the database.
That is not wrong. Postgres expects the kernel to be doing disk
caching,
Hello all,
I'm encountering a quite strange performance problem. Look at the
following two queries and their execution times. The only difference is
the first query has OR operator and the second query has AND operator.
Any ideas?
Thank you in advance,
Federico
[FIRST QUERY: EXEC TIME 0.015 SEC
On Mon, Oct 10, 2005 at 06:28:23PM +0700, Ahmad Fajar wrote:
> than you can index the field and you can gain better
> perfomance in searching base on the fields, because the search uses the
> index you have been created.
That really depends on the queries. An index will help some queries (notably
Tino Wildenhain mentioned :
=> Well, text columns are automatically compressed via the toast mechanism.
=> This is handled transparently for you.
OK, I misread the documentation, and I forgot to mention that
I'm using postgres 7.3 and 8.0
It's actually the EXTERNAL storage type that is larger, not
Stef schrieb:
I have a table in the databases I work with,
that contains two text columns with XML data
stored inside them.
This table is by far the biggest table in the databases,
and the text columns use up the most space.
I saw that the default storage type for text columns is
"EXTENDED"
I have a table in the databases I work with,
that contains two text columns with XML data
stored inside them.
This table is by far the biggest table in the databases,
and the text columns use up the most space.
I saw that the default storage type for text columns is
"EXTENDED" which, according t
Dear Cristian,
If you need to index the field, you must know that it limit the length up to
1000 bytes. So if you need to index the field you must limit the field type,
ex: varchar(250), than you can index the field and you can gain better
perfomance in searching base on the fields, because the se
Yes you're right it really bosst a little.
I want to improve the system performance. Are there any more tipps?
On this server runs only a webserver with php application which uses postgre
Db. Should I give more memory to postgre? From what I noticed this is the
most memory "needing" service fro
A lot of them are too large. Try:
Andy wrote:
Hi to all,
I have the following configuration:
Dual Xeon 2.8 Ghz, 1G RAM and postgre 8.0.3 installed.
Modified configuration parameters:
max_connections = 100
shared_buffers = 64000 # 500MB = 500 x 1024 x 1024 / (8 x 1024) (8KB)
shared_b
Hi to all,
I have the following configuration:
Dual Xeon 2.8 Ghz, 1G RAM and postgre 8.0.3
installed.
Modified configuration parameters:
max_connections = 100
shared_buffers = 64000 # 500MB = 500 x
1024 x 1024 / (8 x 1024) (8KB)work_mem = 51200 # 50MB = 50 x 1024
KBmaintenance_wor
27 matches
Mail list logo
