Let me know what I can send you to help fix the problem, if it isn't
already taken care of.
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
You can also try making mirror sets with the hardware RAID controller
and then doing SW RAID 0 on top of that. Since RAID0 requires little
or no CPU overhead, this is a good compromise because the OS has the
least work to do, and the RAID controller is doing what it's probably
pretty good at, mirror sets.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
What you have not said is how you propose to convert UTF8 to ASCII.
Currently to_ascii() converts a small number of single byte charsets to
ASCII by folding the chars with high bits set, so what we get is a pure
ASCII result which is safe in any server encoding, as they are all ASCII
supersets.
But what conversion rule will you use for the gazillions of Unicode
characters?
I honestly do not understand the use case for this at all.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
Thanks, done :)
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
Date: 2008-08-11 14:01:25 +0100 (Mon, 11 Aug 2008)
New Revision: 7398
Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7398&view=rev
Log:
Support for adding/removing inherited tables with 8.2+ servers.
Modified:
trunk/pgadmin3/CHANGELOG
trunk/pgadmin3/pgadmin/dlg/dlgTable.cpp
trunk/pgadmin3/pgadmin/include/dlg/dlgTable.h
trunk/pgadmin3/pgadmin/include/schema/pgColumn.h
trunk/pgadmin3/pgadmin/include/schema/pgTable.h
trunk/pgadmin3/pgadmin/schema/pgColumn.cpp
trunk/pgadmin3/pgadmin/schema/pgTable.cpp
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
One note - convert_to is correct. But we have to use to_ascii without
decode functions. It has same behave - convert from bytea to text.
Text in "incorrect" encoding is dafacto bytea. So correct to_ascii
function prototypes are:
to_ascii(text)
to_ascii(bytea, integer);
to_ascii(bytea, name);
Regards
Pavel Stehule
>
> We are surely not going to go back to a situation where we have functions
> returning text in any encoding other than the database encoding. That
> becomes a vehicle for storing wrongly encoded data in the database, and we
> have just gone through the exercise of plugging those holes. I privately
> predicted when we did this work that it might motivate people who had been
> abusing convert_to to get proper support for multiple encodings done. That
> is the right way to go, not re-opening holes we have just very deliberately
> plugged.
>
>
>
> cheers
>
> andrew
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> There's already 4 fixes for an 1.8.5. And this one.
>
> Moreover, 1.10 is not expected before PostgreSQL 8.4 (march 2009 IIRC). I
> think it would be better to have another 1.8. Not now, but there's still
> like 7 months to go before next release. Not sure we won't need another
> minor release.
<grumble>We rarely release in the second-half of the PG cycle. Still,
go ahead and backpatch if you like.
>> The only thing that looks a little odd with this patch is that the Add
>> button is always enabled, even if there is no table selected. That is
>> actually the existing behaviour, but it's a little more obvious now
>> the button is enabled when editing existing tables as well. Should we
>> fix that? My gut feeling is yes.
>>
>
> hehe... I saw it but wasn't sure if I should work on that too :)
>
> Anyways, fixed.
Cool, thanks. I'm not going to review it again - please apply.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
Fixed.
>> Fixed in the same patch. Don't know if you want a backpatch for 1.8?
>
> Thanks. I don't expect we're ever going to release another 1.8 - do you?
>
There's already 4 fixes for an 1.8.5. And this one.
Moreover, 1.10 is not expected before PostgreSQL 8.4 (march 2009 IIRC).
I think it would be better to have another 1.8. Not now, but there's
still like 7 months to go before next release. Not sure we won't need
another minor release.
> The only thing that looks a little odd with this patch is that the Add
> button is always enabled, even if there is no table selected. That is
> actually the existing behaviour, but it's a little more obvious now
> the button is enabled when editing existing tables as well. Should we
> fix that? My gut feeling is yes.
>
hehe... I saw it but wasn't sure if I should work on that too :)
Anyways, fixed.
New patch available at:
http://developer.pgadmin.org/~guillaume/inherit82+_20080811.patch.bz2
--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
Are 32/64-bit binaries on Sparc incompatible, then? Does our control
file check catch it? If not, what's causing it, and would the
--footprint switch catch it?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> There are a few instances of this. I think it indicates we are either spelling
> -fpic wrong or including some .o object that was not compiled with -fpic
> (perhaps something from the ports directory?).
If it were the latter, quite a number of platforms would just fail
outright, I believe. As for spelling -fpic wrong, that seems unlikely
too considering that icc generally tries to pretend it's gcc.
Any other theories?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2008/8/11 Andrew Dunstan <andrew@dunslane.net>:
>
>
> Pavel Stehule wrote:
>>
>> Hello,
>>
>> combination functions to_ascii and convert_to is broken now. Problem
>> is in convert_to function. It doesn't support 8bit output encoding.
>>
>> Current workaround:
>>
>> CREATE FUNCTION to_ascii(bytea, name)
>> RETURNS text AS 'to_ascii_encname' LANGUAGE internal;
>>
>> SELECT to_ascii(convert_to('Příliš žlutý kůň', 'latin2'),'latin2');
>>
>> I don't expect column collate for 8.4, so we need to have workable
>> to_ascii function.
>>
>> I propose function to_ascii(text, name) that internally convert text
>> from utf8 encoding when it's necessary.cheers
>>
>>
>>
>
> convert_to is not broken. It returns a bytea, and it is up to you to
> de-escape it if you get the text representation.
>
ok, I talked about combination convert_to and to_ascii. to_ascii
doesn't support bytea, what is probably correct. We cannot use
descape, because it remove 8bit. This issue was noticed more times -
http://archives.postgresql.org/pgsql-general/2008-06/msg00495.php
> We are surely not going to go back to a situation where we have functions
> returning text in any encoding other than the database encoding. That
> becomes a vehicle for storing wrongly encoded data in the database, and we
> have just gone through the exercise of plugging those holes. I privately
> predicted when we did this work that it might motivate people who had been
> abusing convert_to to get proper support for multiple encodings done. That
> is the right way to go, not re-opening holes we have just very deliberately
> plugged.
>
to_ascii isn't related to multiple encodings. And actually there is
only one man who works on it. We will be happy for database collation
in 8.4. So without any change this feature will be broken more than
two years.
Regards
Pavel
>
>
> cheers
>
> andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
----------------------------------------------------------------
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I../../../src/include/snowball -I../../../src/include/snowball/libstemmer -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o stem_UTF_8_swedish.o ./libstemmer/stem_UTF_8_swedish.c
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I../../../src/include/snowball -I../../../src/include/snowball/libstemmer -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o stem_UTF_8_turkish.o ./libstemmer/stem_UTF_8_turkish.c
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -shared dict_snowball.o api.o utilities.o stem_ISO_8859_1_danish.o stem_ISO_8859_1_dutch.o stem_ISO_8859_1_english.o stem_ISO_8859_1_finnish.o stem_ISO_8859_1_french.o stem_ISO_8859_1_german.o stem_ISO_8859_1_hungarian.o stem_ISO_8859_1_italian.o stem_ISO_8859_1_norwegian.o stem_ISO_8859_1_porter.o stem_ISO_8859_1_portuguese.o stem_ISO_8859_1_spanish.o stem_ISO_8859_1_swedish.o stem_ISO_8859_2_romanian.o stem_KOI8_R_russian.o stem_UTF_8_danish.o stem_UTF_8_dutch.o stem_UTF_8_english.o stem_UTF_8_finnish.o stem_UTF_8_french.o stem_UTF_8_german.o stem_UTF_8_hungarian.o stem_UTF_8_italian.o stem_UTF_8_norwegian.o stem_UTF_8_porter.o stem_UTF_8_portuguese.o stem_UTF_8_romanian.o stem_UTF_8_russian.o stem_UTF_8_spanish.o stem_UTF_8_swedish.o stem_UTF_8_turkish.o -L../../../src/port -o dict_snowball.so
ld: warning: creating a DT_TEXTREL in object.
----------------------------------------------------------------
There are a few instances of this. I think it indicates we are either spelling
-fpic wrong or including some .o object that was not compiled with -fpic
(perhaps something from the ports directory?).
This can result in a performance drain when the .so is linked in since the
text segment can't be mapped directly from the file and instead needs to be
read in and adjusted to the base address to which it was loaded.
It isn't unique to tsearch stuff either, plpgsql has the same warning:
----------------------------------------------------------------
make[4]: Entering directory `/home/data/local/jeremyd/postgres/buildfarm/root/HEAD/pgsql.4376/src/pl/plpgsql/src'
bison -y -d gram.y
mv -f y.tab.c ./pl_gram.c
mv -f y.tab.h ./pl.tab.h
LC_CTYPE=C /usr/bin/flex -o'pl_scan.c' scan.l
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I. -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o pl_gram.o pl_gram.c
pl_scan.c(1944) : (col. 2) remark: LOOP WAS VECTORIZED.
pl_scan.c(2495) : (col. 2) remark: LOOP WAS VECTORIZED.
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I. -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o pl_handler.o pl_handler.c
pl_handler.c(199) : (col. 3) remark: LOOP WAS VECTORIZED.
pl_handler.c(200) : (col. 3) remark: LOOP WAS VECTORIZED.
pl_handler.c(206) : (col. 4) remark: LOOP WAS VECTORIZED.
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I. -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o pl_comp.o pl_comp.c
pl_comp.c(157) : (col. 3) remark: LOOP WAS VECTORIZED.
pl_comp.c(211) : (col. 4) remark: LOOP WAS VECTORIZED.
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I. -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o pl_exec.o pl_exec.c
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -I. -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/et -c -o pl_funcs.o pl_funcs.c
icc -O3 -xN -parallel -ip -mp1 -fno-strict-aliasing -g -fpic -shared pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o -L../../../../src/port -o plpgsql.so
ld: warning: creating a DT_TEXTREL in object.
----------------------------------------------------------------
And then there's this -- plen is a size_t...
plpython.c(1420): warning #186: pointless comparison of unsigned integer with zero
Assert(plen >= 0 && plen < mlen);
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Yes, it is extreme case.
>> And maybe there are more compiler magic switches and optimization on
>> different platforms which can modify structure alignment or member
>> order. It probably does not happen often but footprint should protect
>> people to shot himself.
>
> We depend on a certain member order and alignment rules. If we're
> worried about that, we should add checks in configure instead, to barf
> if you try to use such options.
>
You are able to check order, but you cannot complain about structure member
alignment during configure time. But if you have two binaries which you get from
two sources then you need to verify that both binaries has same structure footprint.
Similar is 32/64 bit compilation. It is handled on x86 by MAXALIGN but MAXALIGN
is same on SPARC for both binaries, but I'm not sure if it works correctly.
Any other usage is to protect developers to make a mistake and break silently
compatibility, but it should be caught by --footprint switch.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
select max(length(messageblk)),avg(length(messageblk)) from
dbmail_messageblks
MAX AVG
532259; 48115.630147120314
The query has been running for 6.5 hours now and in the status bar of
the query tool it says "Query is running" and the count in ms is still
running.
I had checked a number of times using select * from pg_stat_activity and
it was in there and running. The last time I checked the query was not
listed in pg_stat_activity. In fact There is no row for that window. I
have 3 windows open for that database, the one running the query, the
one I queried pg_stat_activity from and another one.
When I query pg_stat_activity it shows 2 rows for my ip address, the
pg_stat_activity and an IDLE row. When I close the other window it only
shows one row for my IP address.
I also checked in Linux PS - my IP address only shows up in ps aux for
the other windows, not for this 6.5 hour query.
Is there any way to check what is going on?
Thank you
Sim
--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support
convert_to is not broken. It returns a bytea, and it is up to you to
de-escape it if you get the text representation.
We are surely not going to go back to a situation where we have
functions returning text in any encoding other than the database
encoding. That becomes a vehicle for storing wrongly encoded data in the
database, and we have just gone through the exercise of plugging those
holes. I privately predicted when we did this work that it might
motivate people who had been abusing convert_to to get proper support
for multiple encodings done. That is the right way to go, not re-opening
holes we have just very deliberately plugged.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> "Jay" <arrival123@gmail.com> writes:
>
>> I have a table named table_Users:
>>
>> CREATE TABLE table_Users (
>> UserID character(40) NOT NULL default '',
>> Username varchar(256) NOT NULL default '',
>> Email varchar(256) NOT NULL default ''
>> etc...
>> );
>>
>> The UserID is a character(40) and is generated using UUID function.
>> We
>> started making making other tables and ended up not really using
>> UserID, but instead using Username as the unique identifier for the
>> other tables. Now, we pass and insert the Username to for
>> discussions,
>> wikis, etc, for all the modules we have developed. I was wondering if
>> it would be a performance improvement to use the 40 Character UserID
>> instead of Username when querying the other tables, or if we should
>> change the UserID to a serial value and use that to query the other
>> tables. Or just keep the way things are because it doesn't really
>> make
>> much a difference.
>
> Username would not be any slower than UserID unless you have a lot of
> usernames longer than 40 characters.
>
> However making UserID an integer would be quite a bit more
> efficient. It would
> take 4 bytes instead of as the length of the Username which adds up
> when it's
> in all your other tables... Also internationalized text collations
> are quite a
> bit more expensive than a simple integer comparison.
>
> But the real question here is what's the better design. If you use
> Username
> you'll be cursing if you ever want to provide a facility to allow
> people to
> change their usernames. You may not want such a facility now but one
> day...
>
If you generate UUID's with the UUID function and you are on 8.3,
why not use the UUID type to store it?
Ries
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's On-Demand Production Tuning
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
Ries van Twisk
tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS
WebORB PostgreSQL DB-Architect
email: ries@vantwisk.nl
web: http://www.rvantwisk.nl/
skype: callto://r.vantwisk
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
From gcc man page:
> -fipa-struct-reorg
> Perform structure reorganization optimization, that change C-like
> structures layout in order to better utilize spatial locality.
> This transformation is affective for programs containing arrays of
> structures. Available in two compilation modes: profile-based
> (enabled with -fprofile-generate) or static (which uses built-in
> heuristics). Require -fipa-type-escape to provide the safety of
> this transformation. It works only in whole program mode, so it
> requires -fwhole-program and -combine to be enabled. Structures
> considered cold by this transformation are not affected (see
> --param struct-reorg-cold-struct-ratio=value).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Modified Files:
--------------
wizard:
App.cpp (r1.22 -> r1.23)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/App.cpp.diff?r1=1.22&r2=1.23)
AppList.cpp (r1.15 -> r1.16)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/AppList.cpp.diff?r1=1.15&r2=1.16)
CMakeLists.txt (r1.5 -> r1.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/CMakeLists.txt.diff?r1=1.5&r2=1.6)
wizard/include:
App.h (r1.10 -> r1.11)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/include/App.h.diff?r1=1.10&r2=1.11)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
>>>
>>>> It feels like there is something fishy going on.
>> Maybe the RAID 10
>>>> implementation on the PERC/6e is crap?
>>>
>
> It's possible. We had a bunch of perc/5i SAS raid cards in our
> servers that performed quite well in Raid 5 but were shite in Raid
> 10. I switched them out for Adaptec 5808s and saw a massive
> improvement in Raid 10.
I suspected that. Maybe I should just put the PERC/6 cards in JBOD
mode and then make a RAID10 with linux software raid MD?
>
>
>
> __________________________________________________________
> Not happy with your email address?.
> Get the one you really want - millions of new email addresses
> available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
> By my opinion -fipa-struct-reorg GCC option could break structure. And maybe
> there are more compiler magic switches and optimization on different platforms
> which can modify structure alignment or member order. It probably does not
> happen often but footprint should protect people to shot himself.
My version of GCC doesn't have that option, what does it do?
If structure members aren't in the order they're defined and padded to the
alignment they're declared to have in pg_type then Postgres catalogs won't
work anyways.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
That option would probably break a lot of things. Like our
"variable-sized array as last field of a struct" hacks.
> And
> maybe there are more compiler magic switches and optimization on
> different platforms which can modify structure alignment or member
> order. It probably does not happen often but footprint should protect
> people to shot himself.
We depend on a certain member order and alignment rules. If we're
worried about that, we should add checks in configure instead, to barf
if you try to use such options.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This sounds like your installation is botched? How did you install this?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
The xpath_bool function takes its XML data as type text. The new xpath()
function uses the XML type. Those are two different sets of functions.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Rilasciato BitNami LAPPStack 1.0
http://bitnami.org/stack/lappstack
Rilasciato pgbouncer 1.2.3
http://pgfoundry.org/projects/pgbouncer/
Rilasciato phpPgAdmin 4.2.1
http://sourceforge.net/project/showfiles.php?group_id=37132
Rilasciato PyReplica 1.0.3
http://pgfoundry.org/projects/pyreplica/
Rilasciato Another PostgreSQL Diff Tool 1.2
http://pgfoundry.org/projects/apgdiff/
Rilasciato pgSphere 1.0.1
http://pgfoundry.org/projects/pgsphere/
Rilasciato PostgreSQL Toolbox 1
http://pgfoundry.org/projects/pg-toolbox/
== Offerte di lavoro legate a PostgreSQL per il mese di Agosto ==
http://archives.postgresql.org/pgsql-jobs/2008-08/threads.php
== PostgreSQL news locali ==
Il Prato Linux User Group terrà dei talk su PostgreSQL talks a Settembre.
Il calendario in italiano si trova all'url:
http://www.prato.linux.it/serate_a_tema_2008
Il PGCon Brasile 2008 ci sara' il 26 e 27 settembre 2008 a Unicamp, Campinas.
http://pgcon.postgresql.org.br/index.en.html
Il PgDay.fr ci sarà il 4 ottobrea a Toulouse. Il Call for Papers è aperto:
http://www.postgresqlfr.org/?q=node/1686
Per registrarsi:
http://www.pgday.fr/doku.php/inscription
Sponsorizzate il PGDay Europeo!
http://www.pgday.org/en/sponsors/campaign
E' iniziato il call for papers per il PGDay europeo.
http://www.pgday.org/en/call4papers
Il PGDay.(IT|EU) 2008 ci sarà il 17 e 18 ottobre a Prato.
http://www.pgday.org/it/
== News su PostgreSQL ==
Planet PostgreSQL: http://www.planetpostgresql.org/
General Bits, archivi e nuovi articoli occasionali:
http://www.varlena.com/GeneralBits/
PostgreSQL Weekly News è stato spedito questa settimana grazie a David
Fetter e Devrim GUNDUZ.
Per segnalare news e annunci invia un email in inglese entro le ore 15,
fuso orario della costa orientale degli U.S.A, di domenica.
Per segnalazioni in inglese david@fetter.org, per segnalazioni in
Tedesco pwn@pgug.de, per segnalazioni in italiano pwn@itpug.org
== Patch applicate ==
Tom Lane committed:
- Improve CREATE/DROP/RENAME DATABASE so that when failing because the
source or target database is being accessed by other users, it tells
you whether the "other users" are live sessions or uncommitted
prepared transactions. (Indeed, it tells you exactly how many of
each, but that's mostly just because it was easy to do so.) This
should help forestall the gotcha of not realizing that a prepared
transaction is what's blocking the command. Per discussion.
- Improve SELECT DISTINCT to consider hash aggregation, as well as
sort/uniq, as methods for implementing the DISTINCT step. This
eliminates the former performance gap between DISTINCT and GROUP BY,
and also makes it possible to do SELECT DISTINCT on datatypes that
only support hashing not sorting. SELECT DISTINCT ON is still
always implemented by sorting; it would take executor changes to
support hashing that, and it's not clear it's worth the trouble.
This is a release-note-worthy incompatibility from previous PG
versions, since SELECT DISTINCT can no longer be counted on to
deliver sorted output without explicitly saying ORDER BY. (Anyone
who can't cope with that can consider turning off enable_hashagg.)
Several regression test queries needed to have ORDER BY added to
preserve stable output order. I fixed the ones that manifested
here, but there might be some other cases that show up on other
platforms.
- In pgsql/src/test/regress/pg_regress.c, fix some message style
guideline violations in pg_regress, as well as some failures to
expose messages for translation.
- In pgsql/src/backend/storage/buffer/bufmgr.c, in ReadOrZeroBuffer
(and related entry points), don't bother to call PageHeaderIsValid
when we zero the buffer instead of reading the page in. The actual
performance improvement is probably marginal since this function
isn't very heavily used, but a cycle saved is a cycle earned Zdenek
Kotala
- Add an ORDER BY to one more SELECT DISTINCT test case, per buildfarm
results.
- In pgsql/src/backend/optimizer/plan/planner.c, department of second
thoughts: fix newly-added code in planner.c to make real sure that
DISTINCT ON does what it's supposed to, ie, sort by the full ORDER
BY list before unique-ifying. The error seems masked in simple
cases by the fact that query_planner won't return query pathkeys
that only partially match the requested sort order, but I wouldn't
want to bet that it couldn't be exposed in some way or other.
- Do not allow Unique nodes to be scanned backwards. The code claimed
that it would work, but in fact it didn't return the same rows when
moving backwards as when moving forwards. This would have no
visible effect in a DISTINCT query (at least assuming the column
datatypes use a strong definition of equality), but it gave entirely
wrong answers for DISTINCT ON queries.
- Teach the system how to use hashing for UNION. (INTERSECT/EXCEPT
will follow, but seem like a separate patch since most of the
remaining work is on the executor side.) I took the opportunity to
push selection of the grouping operators for set operations into the
parser where it belongs. Otherwise this is just a small exercise in
making prepunion.c consider both alternatives. As with the recent
DISTINCT patch, this means we can UNION on datatypes that can hash
but not sort, and it means that UNION without ORDER BY is no longer
certain to produce sorted output.
- Support hashing for duplicate-elimination in INTERSECT and EXCEPT
queries. This completes my project of improving usage of hashing
for duplicate elimination (aggregate functions with DISTINCT remain
undone, but that's for some other day). As with the previous
patches, this means we can INTERSECT/EXCEPT on datatypes that can
hash but not sort, and it means that INTERSECT/EXCEPT without ORDER
BY are no longer certain to produce sorted output.
- Improve INTERSECT/EXCEPT hashing by realizing that we don't need to
make any hashtable entries for tuples that are found only in the
second input: they can never contribute to the output. Furthermore,
this implies that the planner should endeavor to put first the
smaller (in number of groups) input relation for an INTERSECT.
Implement that, and upgrade prepunion's estimation of the number of
rows returned by setops so that there's some amount of sanity in the
estimate of which one is smaller.
- In pgsql/src/backend/executor/execMain.c, install checks in executor
startup to ensure that the tuples produced by an INSERT or UPDATE
will match the target table's current rowtype. In pre-8.3 releases
inconsistency can arise with stale cached plans, as reported by
Merlin Moncure. (We patched the equivalent hazard on the SELECT
side in Feb 2007; I'm not sure why we thought there was no risk on
the insertion side.) In 8.3 and HEAD this problem should be
impossible due to plan cache invalidation management, but it seems
prudent to make the check anyway. Back-patch as far as 8.0. 7.x
versions lack ALTER COLUMN TYPE, so there seems no way to abuse a
stale plan comparably.
- Fix corner-case bug introduced with HOT: if REINDEX TABLE pg_class
(or a REINDEX DATABASE including same) is done before a session has
done any other update on pg_class, the pg_class relcache entry was
left with an incorrect setting of rd_indexattr, because the
indexed-attributes set would be first demanded at a time when we'd
forced a partial list of indexes into the pg_class entry, and it
would remain cached after that. This could result in incorrect
decisions about HOT-update safety later in the same session. In
practice, since only pg_class_relname_nsp_index would be missed out,
only ALTER TABLE RENAME and ALTER TABLE SET SCHEMA could trigger a
problem. Per report and test case from Ondrej Jirman.
Magnus Hagander committed:
- Move pgstat.tmp into a temporary directory under $PGDATA named
pg_stat_tmp. This allows the use of a ramdrive (either through
mount or symlink) for the temporary file that's written every half
second, which should reduce I/O. On server shutdown/startup, the
file is written to the old location in the global directory, to
preserve data across restarts. Bump catversion since the $PGDATA
directory layout changed.
== Patch rigettate (per ora) ==
Nessuno è stato scontentato questa settimana :-)
== Patch in attesa ==
ITAGAKI Takahiro sent in a patch to user NDirectFileRead/Write
counters to get I/O counts in BufFile the module. These counters are
visible when log_statement_stats is on.
Pavel Stehule sent in a patch to implement GROUPING SETS.
Tom Lane sent in a patch to use hashes for set operations.
Martin Pihlak sent in a patch to make dropping and re-creating
functions work more nicely with plan invalidation.
Simon Riggs sent in a patch which adds a hook for stats plugins.
Abhijit Menon-Sen sent in a patch which extend has_table_privilege()
to include sequence information.
Robert Haas sent in a patch to implement CREATE OR REPLACE VIEW.
Simon Riggs sent two revisions of a patch to fix pg_stop_backup per
suggestion by Fujii Masao. pg_stop_backup now tests XLogArchiveCheckDone()
for both stopxlogfilename and history file and then stats the stop
WAL.
Marko Kreen sent in a patch to fix a security issue in dblink.
Alvaro Herrera sent in two revisions of a patch to make autovacuum
process TOAST tables separately from main tables.
Volkan YAZICI sent in three revisions of a patch to allow people to
increase the verbosity of set-returning functions.
David Wheeler sent in some touch-ups for his citext patch.
Euler Taveira de Oliveira sent in a patch which allows symlinking
statistics files at initdb time.
--
(all opinions expressed are my own)
Federico Campoli
PostgreSQL Consulting -> PGHost http://www.pghost.eu
--
Sent via pgsql-it-generale mailing list (pgsql-it-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-it-generale
2008/8/11 ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>:
> I'm working on improvements of orafce.
> http://pgfoundry.org/projects/orafce
>
> I found postgres supports only one type of anyelement at one time
> when I added nvl2() and decode(). I'd like to use multiple types of
> anyelement something like:
>
> template < typename Expr, typename Ret >
> CREATE FUNCTION nvl(Expr, Ret, Ret) RETURNS Ret
>
> template < typename Expr, typename Ret >
> CREATE FUNCTION decode(Expr, Expr, Ret, ..., Ret) RETURNS Ret
>
> I don't mean to propose the above C++-like syntax, but such feature
> is important to develop a generic porting tool. Two independent
> anyelements are enough for me, but three or more might be better
> for general use.
>
it's good idea - I though so 2 independent types are enough:
anyelement2, enyarray2. If you are C coder, you should use "any" type.
regards
Pavel Stehule
> What syntax is suitable for postgres? Comments welcome.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The bulk of this patch is about changing the smgr API to include an extra
ForkNumber argument in every smgr function. Also, smgrscheduleunlink and
smgrdounlink no longer implicitly call smgrclose, because other forks might
still exist after unlinking one. The callers of those functions have been
modified to call smgrclose instead.
This patch in itself doesn't have any user-visible effect, but provides the
infrastructure needed for upcoming patches. The additional forks envisioned
are a rewritten FSM implementation that doesn't rely on a fixed-size shared
memory block, and a visibility map to allow skipping portions of a table in
VACUUM that have no dead tuples.
Modified Files:
--------------
pgsql/src/backend/access/hash:
hashpage.c (r1.75 -> r1.76)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/hash/hashpage.c?r1=1.75&r2=1.76)
pgsql/src/backend/access/heap:
heapam.c (r1.261 -> r1.262)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/heapam.c?r1=1.261&r2=1.262)
rewriteheap.c (r1.14 -> r1.15)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/rewriteheap.c?r1=1.14&r2=1.15)
pgsql/src/backend/access/nbtree:
nbtsort.c (r1.116 -> r1.117)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtsort.c?r1=1.116&r2=1.117)
pgsql/src/backend/access/transam:
twophase.c (r1.44 -> r1.45)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/twophase.c?r1=1.44&r2=1.45)
xact.c (r1.264 -> r1.265)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.264&r2=1.265)
xlog.c (r1.316 -> r1.317)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.316&r2=1.317)
xlogutils.c (r1.57 -> r1.58)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlogutils.c?r1=1.57&r2=1.58)
pgsql/src/backend/catalog:
catalog.c (r1.77 -> r1.78)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/catalog.c?r1=1.77&r2=1.78)
heap.c (r1.336 -> r1.337)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/heap.c?r1=1.336&r2=1.337)
index.c (r1.301 -> r1.302)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/index.c?r1=1.301&r2=1.302)
pgsql/src/backend/commands:
tablecmds.c (r1.261 -> r1.262)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.261&r2=1.262)
pgsql/src/backend/postmaster:
bgwriter.c (r1.50 -> r1.51)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/bgwriter.c?r1=1.50&r2=1.51)
pgsql/src/backend/rewrite:
rewriteDefine.c (r1.127 -> r1.128)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/rewrite/rewriteDefine.c?r1=1.127&r2=1.128)
pgsql/src/backend/storage/buffer:
bufmgr.c (r1.236 -> r1.237)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/buffer/bufmgr.c?r1=1.236&r2=1.237)
localbuf.c (r1.80 -> r1.81)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/buffer/localbuf.c?r1=1.80&r2=1.81)
pgsql/src/backend/storage/smgr:
README (r1.5 -> r1.6)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README?r1=1.5&r2=1.6)
md.c (r1.138 -> r1.139)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/md.c?r1=1.138&r2=1.139)
smgr.c (r1.110 -> r1.111)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/smgr.c?r1=1.110&r2=1.111)
pgsql/src/backend/utils/adt:
dbsize.c (r1.19 -> r1.20)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/dbsize.c?r1=1.19&r2=1.20)
pgsql/src/include/access:
heapam.h (r1.137 -> r1.138)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/heapam.h?r1=1.137&r2=1.138)
htup.h (r1.100 -> r1.101)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/htup.h?r1=1.100&r2=1.101)
xact.h (r1.94 -> r1.95)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xact.h?r1=1.94&r2=1.95)
xlog_internal.h (r1.23 -> r1.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlog_internal.h?r1=1.23&r2=1.24)
xlogutils.h (r1.25 -> r1.26)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlogutils.h?r1=1.25&r2=1.26)
pgsql/src/include/catalog:
catalog.h (r1.40 -> r1.41)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catalog.h?r1=1.40&r2=1.41)
pgsql/src/include/postmaster:
bgwriter.h (r1.11 -> r1.12)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/postmaster/bgwriter.h?r1=1.11&r2=1.12)
pgsql/src/include/storage:
buf_internals.h (r1.97 -> r1.98)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/buf_internals.h?r1=1.97&r2=1.98)
bufmgr.h (r1.114 -> r1.115)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/bufmgr.h?r1=1.114&r2=1.115)
relfilenode.h (r1.15 -> r1.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/relfilenode.h?r1=1.15&r2=1.16)
smgr.h (r1.62 -> r1.63)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/smgr.h?r1=1.62&r2=1.63)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Current control file contain following information (related to page layout):
maxAlign
blcksz
toast_max_chunk_size
But you don't have control how aligned is each member of data structure.
By my opinion -fipa-struct-reorg GCC option could break structure. And maybe
there are more compiler magic switches and optimization on different platforms
which can modify structure alignment or member order. It probably does not
happen often but footprint should protect people to shot himself.
Zdenek
PS: And of course toast_max_chunk_size is not insufficient as well. There are
more constants like MaxHeapTupleSize and so on, but it is different story.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This looks good, with a couple of tweaks. I don't think we are going to be
making these kinds of changes in the 8.2 and 8.3 branches, so I suggest you
prepare a patch for 8.4. Some of the makefiles have changed, so a bit of
work might be involved.
> 2. in various makefiles, checking BUILDOS not PORTNAME when deciding
> whether to use 'pwd -W' or just 'pwd'
I was wondering, what is the difference between these? And couldn't we just
use $(CURDIR) instead?
> 5. Working round a binutils-2.18 bug in windres when the rc file has /
> or \ in the path
What is the status of this bug? Shouldn't it be fixed instead?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I think the -L option only exists for legacy reasons.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
It's possible. We had a bunch of perc/5i SAS raid cards in our servers that performed quite well in Raid 5 but were shite in Raid 10. I switched them out for Adaptec 5808s and saw a massive improvement in Raid 10.
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Modified Files:
--------------
wizard:
CMakeLists.txt (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/CMakeLists.txt.diff?r1=1.4&r2=1.5)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
莫建祥
阿里巴巴软件(上海)有限公司
研发中心－IM服务端开发部
联系方式:86-0571-85022088-13072
贸易通ID:jaymo 淘宝ID:jackem
公司网站:www.alisoft.com
wiki:http://10.0.32.21:1688/confluence/pages/viewpage.action?pageId=10338
-----邮件原件-----
发件人: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org] 代表 Jay
发送时间: 2008年8月11日 15:35
收件人: pgsql-performance@postgresql.org
主题: [PERFORM] Using PK value as a String
I have a table named table_Users:
CREATE TABLE table_Users (
UserID character(40) NOT NULL default '',
Username varchar(256) NOT NULL default '',
Email varchar(256) NOT NULL default ''
etc...
);
The UserID is a character(40) and is generated using UUID function. We
started making making other tables and ended up not really using
UserID, but instead using Username as the unique identifier for the
other tables. Now, we pass and insert the Username to for discussions,
wikis, etc, for all the modules we have developed. I was wondering if
it would be a performance improvement to use the 40 Character UserID
instead of Username when querying the other tables, or if we should
change the UserID to a serial value and use that to query the other
tables. Or just keep the way things are because it doesn't really make
much a difference.
We are still in development and its about half done, but if there is
going to be performance issues because using PK as a String value, we
can just take a day change it before any production as been started.
Anyway advice you can give would be much appreciated.
Postgres performance guru where are you?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
> From: Gregory Stark <stark@enterprisedb.com>
> Subject: Re: [PERFORM] Using PK value as a String
> To: "Jay" <arrival123@gmail.com>
> Cc: pgsql-performance@postgresql.org
> Date: Monday, 11 August, 2008, 10:30 AM
> "Jay" <arrival123@gmail.com> writes:
>
> > I have a table named table_Users:
> >
> > CREATE TABLE table_Users (
> > UserID character(40) NOT NULL default
> '',
> > Username varchar(256) NOT NULL default
> '',
> > Email varchar(256) NOT NULL default
> ''
> > etc...
> > );
> >
> > The UserID is a character(40) and is generated using
> UUID function. We
> > started making making other tables and ended up not
> really using
> > UserID, but instead using Username as the unique
> identifier for the
> > other tables. Now, we pass and insert the Username to
> for discussions,
> > wikis, etc, for all the modules we have developed. I
> was wondering if
> > it would be a performance improvement to use the 40
> Character UserID
> > instead of Username when querying the other tables, or
> if we should
> > change the UserID to a serial value and use that to
> query the other
> > tables. Or just keep the way things are because it
> doesn't really make
> > much a difference.
>
> Username would not be any slower than UserID unless you
> have a lot of
> usernames longer than 40 characters.
>
> However making UserID an integer would be quite a bit more
> efficient. It would
> take 4 bytes instead of as the length of the Username which
> adds up when it's
> in all your other tables... Also internationalized text
> collations are quite a
> bit more expensive than a simple integer comparison.
>
> But the real question here is what's the better design.
> If you use Username
> you'll be cursing if you ever want to provide a
> facility to allow people to
> change their usernames. You may not want such a facility
> now but one day...
>
I don't understand Gregory's suggestion about the design. I thought using natural primary keys as opposed to surrogate ones is a better design strategy, even when it comes to performance considerations and even more so if there are complex relationships within the database.
Regards,
Valentin
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's On-Demand Production
> Tuning
>
> --
> Sent via pgsql-performance mailing list
> (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
I found postgres supports only one type of anyelement at one time
when I added nvl2() and decode(). I'd like to use multiple types of
anyelement something like:
template < typename Expr, typename Ret >
CREATE FUNCTION nvl(Expr, Ret, Ret) RETURNS Ret
template < typename Expr, typename Ret >
CREATE FUNCTION decode(Expr, Expr, Ret, ..., Ret) RETURNS Ret
I don't mean to propose the above C++-like syntax, but such feature
is important to develop a generic porting tool. Two independent
anyelements are enough for me, but three or more might be better
for general use.
What syntax is suitable for postgres? Comments welcome.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I have a table named table_Users:
>
> CREATE TABLE table_Users (
> UserID character(40) NOT NULL default '',
> Username varchar(256) NOT NULL default '',
> Email varchar(256) NOT NULL default ''
> etc...
> );
>
> The UserID is a character(40) and is generated using UUID function. We
> started making making other tables and ended up not really using
> UserID, but instead using Username as the unique identifier for the
> other tables. Now, we pass and insert the Username to for discussions,
> wikis, etc, for all the modules we have developed. I was wondering if
> it would be a performance improvement to use the 40 Character UserID
> instead of Username when querying the other tables, or if we should
> change the UserID to a serial value and use that to query the other
> tables. Or just keep the way things are because it doesn't really make
> much a difference.
Username would not be any slower than UserID unless you have a lot of
usernames longer than 40 characters.
However making UserID an integer would be quite a bit more efficient. It would
take 4 bytes instead of as the length of the Username which adds up when it's
in all your other tables... Also internationalized text collations are quite a
bit more expensive than a simple integer comparison.
But the real question here is what's the better design. If you use Username
you'll be cursing if you ever want to provide a facility to allow people to
change their usernames. You may not want such a facility now but one day...
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
> After a cursory glance at the HeapTupleHeaderData structure, it appears it
> could be aligned with INTALIGN instead of MAXALIGN. The one structure I was
> worried about was the 6 byte t_ctid structure. The comments in
> src/include/storage/itemptr.h file indicate the ItemPointerData structure is
> composed of 3 int16 fields. So everthing in the HeapTupleHeaderData
> structure is 32-bits or less.
Sure, but the tuple itself could contain something with double alignment. If
you have a bigint or double in the tuple then heap_form_tuple needs to know
where to put it so it ends up at right alignment.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Is the iozone tests faulty?
What is your suggestions? Trust the IOZone tests and use RAID5 instead
of RAID10, or go for RAID10 as it should be faster and will be more
suited when we add more disks in the future?
I'm a little confused by the benchmarks.
This is from the RAID5 tests on 4 SAS 15K drives...
iozone -e -i0 -i1 -i2 -i8 -t1 -s 1000m -r 8k -+u -F /database/iotest
Children see throughput for 1 random writers = 112074.58 KB/sec
Parent sees throughput for 1 random writers = 111962.80 KB/sec
Min throughput per process = 112074.58 KB/sec
Max throughput per process = 112074.58 KB/sec
Avg throughput per process = 112074.58 KB/sec
Min xfer = 1024000.00 KB
CPU utilization: Wall time 9.137 CPU time 0.510 CPU
utilization 5.58 %
9 aug 2008 kl. 04.24 skrev david@lang.hm:
> On Fri, 8 Aug 2008, Henrik wrote:
>
>> But random writes should be faster on a RAID10 as it doesn't need
>> to calculate parity. That is why people suggest RAID 10 for
>> datases, correct?
>>
>> I can understand that RAID5 can be faster with sequential writes.
>
> the key word here is "can" be faster, it depends on the exact
> implementation, stripe size, OS caching, etc.
>
> the ideal situation would be that the OS would flush exactly one
> stripe of data at a time (aligned with the array) and no reads would
> need to be done, mearly calculate the parity info for the new data
> and write it all.
>
> the worst case is when the write size is small in relation to the
> stripe size and crosses the stripe boundry. In that case the system
> needs to read data from multiple stripes to calculate the new parity
> and write the data and parity data.
>
> I don't know any systems (software or hardware) that meet the ideal
> situation today.
>
> when comparing software and hardware raid, one other thing to
> remember is that CPU and I/O bandwidth that's used for software raid
> is not available to do other things.
>
> so a system that benchmarks much faster with software raid could end
> up being significantly slower in practice if it needs that CPU and I/
> O bandwidth for other purposes.
>
> examples could be needing the CPU/memory capacity to search through
> amounts of RAM once the data is retrieved from disk, or finding that
> you have enough network I/O that it combines with your disk I/O to
> saturate your system busses.
>
> David Lang
>
>
>> //Henke
>>
>> 8 aug 2008 kl. 16.53 skrev Luke Lonergan:
>>
>>> Your expected write speed on a 4 drive RAID10 is two drives worth,
>>> probably 160 MB/s, depending on the generation of drives.
>>> The expect write speed for a 6 drive RAID5 is 5 drives worth, or
>>> about 400 MB/s, sans the RAID5 parity overhead.
>>> - Luke
>>> ----- Original Message -----
>>> From: pgsql-performance-owner@postgresql.org <pgsql-performance-owner@postgresql.org
>>> >
>>> To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org
>>> >
>>> Sent: Fri Aug 08 10:23:55 2008
>>> Subject: [PERFORM] Filesystem benchmarking for pg 8.3.3 server
>>> Hello list,
>>> I have a server with a direct attached storage containing 4 15k SAS
>>> drives and 6 standard SATA drives.
>>> The server is a quad core xeon with 16GB ram.
>>> Both server and DAS has dual PERC/6E raid controllers with 512 MB
>>> BBU
>>> There is 2 raid set configured.
>>> One RAID 10 containing 4 SAS disks
>>> One RAID 5 containing 6 SATA disks
>>> There is one partition per RAID set with ext2 filesystem.
>>> I ran the following iozone test which I stole from Joshua Drake's
>>> test
>>> at
>>> http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/
>>> I ran this test against the RAID 5 SATA partition
>>> #iozone -e -i0 -i1 -i2 -i8 -t1 -s 1000m -r 8k -+u
>>> With these random write results
>>>
>>> Children see throughput for 1 random writers = 168647.33
>>> KB/sec
>>> Parent sees throughput for 1 random writers = 168413.61
>>> KB/sec
>>> Min throughput per process = 168647.33
>>> KB/sec
>>> Max throughput per process = 168647.33
>>> KB/sec
>>> Avg throughput per process = 168647.33
>>> KB/sec
>>> Min xfer = 1024000.00
>>> KB
>>> CPU utilization: Wall time 6.072 CPU time 0.540
>>> CPU
>>> utilization 8.89 %
>>> Almost 170 MB/sek. Not bad for 6 standard SATA drives.
>>> Then I ran the same thing against the RAID 10 SAS partition
>>>
>>> Children see throughput for 1 random writers = 68816.25
>>> KB/sec
>>> Parent sees throughput for 1 random writers = 68767.90
>>> KB/sec
>>> Min throughput per process = 68816.25
>>> KB/sec
>>> Max throughput per process = 68816.25
>>> KB/sec
>>> Avg throughput per process = 68816.25
>>> KB/sec
>>> Min xfer = 1024000.00
>>> KB
>>> CPU utilization: Wall time 14.880 CPU time 0.520
>>> CPU
>>> utilization 3.49 %
>>> What only 70 MB/sek?
>>> Is it possible that the 2 more spindles for the SATA drives makes
>>> that
>>> partition soooo much faster? Even though the disks and the RAID
>>> configuration should be slower?
>>> It feels like there is something fishy going on. Maybe the RAID 10
>>> implementation on the PERC/6e is crap?
>>> Any pointers, suggestion, ideas?
>>> I'm going to change the RAID 10 to a RAID 5 and test again and see
>>> what happens.
>>> Cheers,
>>> Henke
>>> --
>>> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
>>> )
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
That's rather strange. There really should be *something* in the logs
there. Hmm.
Does this happen for just this one dump, or does it happen for all dumps
you create on this machine (for example, can you dump single tables and
get those to come through - thus isolating the issue to one table or so)?
//Magnus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Ok. Good to know - if you want to use it, there are bound to be a number
of others who would like it as well :)
>>> It wouldn't be very easy/clean to do that w/o breaking the existing
>>> structure of pg_ident though, which makes me feel like using seperate
>>> files is probably the way to go.
>> Yeah, thats my feeling as well. Now, can someone figure out a way to do
>> that without parsing the file in the postmaster? (And if we do parse it,
>> there's no point in not storing the parsed version, IMHO). And if not,
>> the question it comes down to is which is most important - keeping the
>> parsing away, or being able to do this ;-)
>
> I don't have an answer wrt the parsing issue, but I definitely want to
> be able to do this. :)
Right.
I guess one option would be to load the map file at runtime in the
backend, and not pre-load/cache it from the postmaster. But that seems
rahter sub-optimal to me. Other thoughts?
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On the homepage we have a number of links that point to the binaries
section of our ftp site, to encourage people to upgrade as well as
install for the first time. The problem is, most of the binaries we
offer in the downloads section don't actually live on our ftp site, so
for may people these links are useless and misleading. I propose we
change that section of the home page to look something like:
Latest Releases
8.3.3: Notes
8.2.9: Notes
8.1.13: Notes
8.0.17: Notes
7.4.21: Notes
<link to /downloads>Downloads</link>
RSS | Why should I upgrade?
The downside is that this may lead to a couple of extra clicks for
people to find what they need. The upside is that the pages they go to
will almost certainly have a section for the packages they actually
want, and should be more simple and easy to understand.
Thoughts?
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
