Hi
Running VACUUM VERBOSE will give you a detailed view of space usage of
each individual table.
I did that.
Not too sure what I'm looking for, can someone tell me what this means:
INFO: blahxxx: scanned 27 of 27 pages, containing 1272 live rows and
0 dead rows; 1272 rows in sample, 1272
This week I've finished building and installing OSes on some new hardware
at home. I have a pretty standard validation routine I go through to make
sure PostgreSQL performance is good on any new system I work with. Found
a really strange behavior this time around that seems related to changes
Adrian Moisey wrote:
Hi
Running VACUUM VERBOSE will give you a detailed view of space usage of
each individual table.
I did that.
Not too sure what I'm looking for, can someone tell me what this means:
INFO: blahxxx: scanned 27 of 27 pages, containing 1272 live rows and
0 dead rows; 1272
Hi
You are tracking ~ 4.6 million pages and have space to track ~ 15.5
million, so that's fine. You are right up against your limit of
relations (tables, indexes etc) being tracked though - 1200. You'll
probably want to increase max_fsm_relations - see manual for details
(server
Hi
INFO: blahxxx: scanned 27 of 27 pages, containing 1272 live rows
and 0 dead rows; 1272 rows in sample, 1272 estimated total rows
This is a small table that takes up 27 pages and it scanned all of them.
You have 1272 rows in it and none of them are dead (i.e. deleted/updated
but still
Adrian Moisey wrote:
Hi
INFO: blahxxx: scanned 27 of 27 pages, containing 1272 live rows
and 0 dead rows; 1272 rows in sample, 1272 estimated total rows
This is a small table that takes up 27 pages and it scanned all of
them. You have 1272 rows in it and none of them are dead (i.e.
Hi there,
I have a table which looks similar to:
CREATE TABLE accounting
(
id text NOT NULL,
time timestamp with time zone,
data1 int,
data2 int,
data3 int,
data4 int,
data5 int,
data6 int,
data7 int,
data8 int,
state int
CONSTRAINT accounting_pkey PRIMARY KEY (id),
)
The table has
Gunther Mayer wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql
it should then also never touch the time index and incur zero overhead
in its presence, but is this really the case? If it
On Thu, Apr 17, 2008 at 2:57 PM, Gunther Mayer
[EMAIL PROTECTED] wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql it
should then also never touch the time index and incur zero overhead in
Hi,
I need to change the name of the constraint.,
What will be the best way to do this.
Am using postgres 8.1.
Is it possible to do the rename constraint( like renaming a column), i don't
know how to do this ?
Or i need to drop the constraint, and i need to create constraint with new
name,
On 17.04.2008, at 14:03, sathiya psql wrote:
Hi,
I need to change the name of the constraint.,
Or i need to drop the constraint, and i need to create constraint
with new
name, how the impact of this in performance, because these constraint
changes am going to do in a table which has 10
Pavan Deolasee wrote:
On Thu, Apr 17, 2008 at 2:57 PM, Gunther Mayer
[EMAIL PROTECTED] wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql it
should then also never touch the time index and
On Thu, 17 Apr 2008, Greg Smith wrote:
So in the case of this simple benchmark, I see an enormous performance
regression from the newest Linux kernel compared to a much older one. I need
to do some version bisection to nail it down for sure, but my guess is it's
the change to the Completely
On Wed, 2008-04-16 at 11:09 -0400, Tom Lane wrote:
Gavin M. Roy [EMAIL PROTECTED] writes:
In 8.3.0, I'm seeing some oddities with SQL functions which I thought were
immune to the planner data restrictions of plpgsql functions and the sort.
Without a specific example this discussion is
Simon Riggs [EMAIL PROTECTED] writes:
I think it would help if there was some way to prepare functions to
allow them to be posted and understood more easily. These would help:
* a name obfuscator, so people can post functions without revealing
inner workings of their company and potentially
On Thu, 2008-04-17 at 12:12 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think it would help if there was some way to prepare functions to
allow them to be posted and understood more easily. These would help:
* a name obfuscator, so people can post functions without
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-04-17 at 12:12 -0400, Tom Lane wrote:
Aren't these suggestions mutually contradictory?
No, they're orthogonal. The pretty printer would get the indenting and
line feeds correct, the obfuscator would replace actual names with A,
B or Table1
On Thu, 2008-04-17 at 12:41 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-04-17 at 12:12 -0400, Tom Lane wrote:
Aren't these suggestions mutually contradictory?
No, they're orthogonal. The pretty printer would get the indenting and
line feeds correct, the
Simon Riggs wrote:
Obfuscating the names would make the code harder to understand, true,
but only if the code is written in English (or your language-of-choice).
It wouldn't damage our ability to read other language code at all.
Speaking of this sort of support tool, what I personally often
On Thu, Apr 17, 2008 at 12:58 AM, Greg Smith [EMAIL PROTECTED] wrote:
So in the case of this simple benchmark, I see an enormous performance
regression from the newest Linux kernel compared to a much older one.
This has been discussed recently on linux-kernel. It's definitely a
regression.
Craig Ringer wrote:
Simon Riggs wrote:
Obfuscating the names would make the code harder to understand, true,
but only if the code is written in English (or your language-of-choice).
It wouldn't damage our ability to read other language code at all.
Speaking of this sort of support tool,
On Thu, 17 Apr 2008, Jeffrey Baker wrote:
On Thu, Apr 17, 2008 at 12:58 AM, Greg Smith [EMAIL PROTECTED] wrote:
So in the case of this simple benchmark, I see an enormous performance
regression from the newest Linux kernel compared to a much older one.
This has been discussed recently on
On Thu, 17 Apr 2008, Jeffrey Baker wrote:
This has been discussed recently on linux-kernel.
Excellent pointer, here's direct to the interesting link there:
http://marc.info/?l=linux-kernelm=120574906013029w=2
Ingo's test system has 16 cores and dives hard at 32 clients; my 4-core
system
On Mon, 31 Mar 2008, James Mansion wrote:
I have a question about file writes, particularly on POSIX.
In other reading I just came across this informative article on this
issue, which amusingly was written the same day you asked about this:
http://jeffr-tech.livejournal.com/20707.html
--
Hi List;
I have a large tble (playback_device) with 6million rows in it. The
aff_id_tmp1 table has 600,000 rows.
I also have this query:
select distinct
tmp1.affiliate_id,
tmp1.name,
tmp1.description,
tmp1.create_dt,
tmp1.playback_device_id,
pf.segment_id
from
aff_id_tmp1 tmp1,
On Thu, Apr 17, 2008 at 11:24 AM, kevin kempter
[EMAIL PROTECTED] wrote:
Hi List;
I have a large tble (playback_device) with 6million rows in it. The
aff_id_tmp1 table has 600,000 rows.
- why am I still getting a seq scan ?
You're selecting almost all the rows in the product of
kevin kempter escribió:
Hi List;
I have a large tble (playback_device) with 6million rows in it. The
aff_id_tmp1 table has 600,000 rows.
I also have this query:
select distinct
tmp1.affiliate_id,
tmp1.name,
tmp1.description,
tmp1.create_dt,
tmp1.playback_device_id,
pf.segment_id
from
Greg Smith schrieb:
You also didn't mention what disk controller you have, or how much write
cache it has (if any).
8.3.1, Controller is
http://www.infortrend.com/main/2_product/es_a08(12)f-g2422.asp with 2GB
cache (writeback was enabled).
That's almost turning the background writer off.
Craig Ringer [EMAIL PROTECTED] writes:
Speaking of this sort of support tool, what I personally often wish for
is unique error message identifiers that can be looked up (say, with a
web form) or a way to un/re-translate localized messages.
The VERBOSE option already gives an exact pointer
- why am I still getting a seq scan ?
You'll seq scan tmp1 obviously, and also the other table since you fetch a
very large part of it in the process.
It's the only way to do this query since there is no WHERE to restrict the
number of rows and the DISTINCT applies on columns from both
On Thu, 17 Apr 2008, Matthew wrote:
The last message in the thread says that 2.6.25-rc6 has the problem nailed.
That was a month ago. So I guess, upgrade to 2.6.25, which was released
today.
Ah, even more support for me to distrust everything I read. The change
has flattened out things, so
On Thu, 17 Apr 2008, Greg Smith wrote:
On Thu, 17 Apr 2008, Matthew wrote:
The last message in the thread says that 2.6.25-rc6 has the problem nailed.
That was a month ago. So I guess, upgrade to 2.6.25, which was released
today.
Ah, even more support for me to distrust everything I read.
On Thu, 17 Apr 2008, [EMAIL PROTECTED] wrote:
report this to the kernel list so that they know, and be ready to test fixes.
Don't worry, I'm on that. I'm already having enough problems with
database performance under Linux, if they start killing results on the
easy benchmarks I'll really
Tom Lane wrote:
Craig Ringer [EMAIL PROTECTED] writes:
Speaking of this sort of support tool, what I personally often wish for
is unique error message identifiers that can be looked up (say, with a
web form) or a way to un/re-translate localized messages.
The VERBOSE option already
I am trying to get a distinct set of rows from 2 tables.
After looking at someone else's query I noticed they were doing a group by
to obtain the unique list.
After comparing on multiple machines with several tables, it seems using
group by to obtain a distinct list is substantially faster
Craig Ringer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Craig Ringer [EMAIL PROTECTED] writes:
Speaking of this sort of support tool, what I personally often wish for
is unique error message identifiers that can be looked up (say, with a
web form) or a way to un/re-translate localized
Tom Lane wrote:
Craig Ringer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Craig Ringer [EMAIL PROTECTED] writes:
Speaking of this sort of support tool, what I personally often wish for
is unique error message identifiers that can be looked up (say, with a
web form) or a way to
Greg Smith [EMAIL PROTECTED] writes:
This is what happens when the kernel developers are using results from a
MySQL tool to optimize things I guess. It seems I have a lot of work
ahead of me here to nail down and report what's going on here.
Yeah, it's starting to be obvious that we'd
38 matches
Mail list logo
