Justin Clift [EMAIL PROTECTED] writes:
Mark kirkwood wrote:
Indeed it is - obtained qsort.c from Freebsd CVS and rebuilt Postgresql :
The query now takes 6 seconds instead of 1 hour ! Thanks for an
excellent suggestion.
How about we include this and have configure somehow ensure the Solaris
Daniel Kalchev [EMAIL PROTECTED] writes:
There is more to it:
customer=# select max(oid) from croute;
max
-
-2144025472
(1 row)
How to handle this?
Use a more recent Postgres release. max(oid) behaves as expected in
7.2. Before that it was piggybacking on
Hi,
It's a stupid thing ... but really useful ...
When we use, like me, psql all the time with the function VACUUM, psql
make the completion of tables names, and of the word ANALYZE ...
Why not the same for VERBOSE ? and for the new function FULL, and FREEZE
??
May be in the TODO for next
Gavin Sherry wrote:
On Wed, 3 Apr 2002, Mikhail Terekhov wrote:
Tom Lane wrote:
There is a very significant performance problem with LISTEN/NOTIFY
via pg_listener: in any application that generates notifications at
a significant rate, pg_listener will accumulate dead tuples at that
same rate,
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
Would it be an idea to have pg_dump append an ANALYZE; command to the end of
its dumps to assist newbies / inexperienced admins?
I do not think this is desired behaviour.
I
Hi All,
With regards to the proposed command.c refactoring...
I've done it by removing command.c and replacing it with
portal.c
alter.c
lock.c
namespace.c
Is that a good idea? Will it break too many outstanding patches?
Basically the portal fetch/destroy commands go in portal.c, all the
On Wed, 2002-04-03 at 09:39, Christopher Kings-Lynne wrote:
Hi All,
With regards to the proposed command.c refactoring...
..about which I should apologise as I stuck my head above the parapet
and then sat on my ideas (mixing metaphors a bit).
I've done it by removing command.c and
Just curious - why is solaris qsort that way? Any good reasons? I saw a
very old post by a solaris guy, but it didn't seem very convincing.
By the way are there faster sorts which Postgresql can use for its sorting
other than quick sort? e.g. BSD 4.4 radixsort (which DJB seems to keep
going
Tom,
I sent a list of items I would like to work on for my Master's Project
yesterday, but didn't hear back. I don't want to be a pest, but was
wondering when you turned on your anti-spam software -- is it possible I got
kicked out and you didn't get my reply?
Thanks,
Mike Shelton
Take this update statement:
update mytable set foo=foo+1 where bar='xxx';
If that gets executed more than once at the same time by multiple instances of
postgresql. Will foo ever lose a count?
I am assumed that foo will always be correct and that the database will manage
any contention, but
Tom Lane wrote:
There is a very significant performance problem with LISTEN/NOTIFY
via pg_listener: in any application that generates notifications at
a significant rate, pg_listener will accumulate dead tuples at that
same rate, and we will soon find ourselves wasting lots of time
Take this update statement:
update mytable set foo=foo+1 where bar='xxx';
If that gets executed more than once at the same time by multiple instances of
postgresql. Will foo ever lose a count?
I am assumed that foo will always be correct and that the database will manage
any contention, but
I am full agreement with proposal. I love it!!
(1) const or constant
(2) cacheable
(3) volatile
P.S.
Tom: My mail doesn't reach you. As an ATT user, you block my machine's IP
address with the anti-spam blocking. :-(
---(end of broadcast)---
TIP
On Wed, 3 Apr 2002, Mikhail Terekhov wrote:
Tom Lane wrote:
There is a very significant performance problem with LISTEN/NOTIFY
via pg_listener: in any application that generates notifications at
a significant rate, pg_listener will accumulate dead tuples at that
same rate, and
On Tue, 2 Apr 2002, Barry Lind wrote:
Since both the JDBC and ODBC specs have essentially the same symantics
for this, I would hope this is done in the backend instead of both
interfaces.
The current plan seems to be to make changes in the backend and the JDBC
interface, the bulk of the
Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Mark kirkwood wrote:
Indeed it is - obtained qsort.c from Freebsd CVS and rebuilt Postgresql :
The query now takes 6 seconds instead of 1 hour ! Thanks for an
excellent suggestion.
How about we include this and have configure
Gavin Sherry [EMAIL PROTECTED] writes:
Because there is no other easy way to guarantee message delivery?
Shared memory is much easier and, to all intents and purposes, as reliable
for this kind of usage. It is much faster and is the-right-way-to-do-it.
Right. Since we do not attempt to
On Wed, Apr 03, 2002 at 10:23:41AM -0500, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
How about we include this and have configure somehow ensure the Solaris
users get it automatically?
Hmm. I suppose there'd be no license issues with borrowing a BSD qsort.
But I can't see
mlw [EMAIL PROTECTED] writes:
I noticed poor performance on Solaris, does one see this problem
when compiling PostgreSQL with gcc on solaris?
Since it's libc that's the culprit, I would imagine so.
As a suggestion, why not find the *best* version of qsort available,
anywhere, and always
Doug McNaught wrote:
mlw [EMAIL PROTECTED] writes:
I noticed poor performance on Solaris, does one see this problem
when compiling PostgreSQL with gcc on solaris?
Since it's libc that's the culprit, I would imagine so.
Thanks, that explains what I have seen.
As a suggestion, why
mlw [EMAIL PROTECTED] writes:
(1) const or constant
(2) cacheable
(3) volatile
I was wondering about const for case 1, also. I think there is some
precedent for using const with this meaning in other programming
languages. volatile for case 3 seems reasonable.
Tom: My mail doesn't reach
mlw [EMAIL PROTECTED] writes:
Because qsort() is *supposed* to be optimized by the vendor for their
platform, perhaps even written in assembler. It makes sense to trust
the vendor except when their implementation is provably pessimized.
Perhaps *supposed* to be optimized, but, in
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Tom: My mail doesn't reach you. As an ATT user, you block my machine's IP
address with the anti-spam blocking. :-(
Sorry about that. I like 510sg's dnsbl list precisely because it's
aggressive, but sometimes it's too aggressive. I can
Christopher Kings-Lynne writes:
usa=# \i ~/ddlpack/kl_setnotnull.sql -- tab completes properly
~/ddlpack/kl_setnotnull.sql: No such file or directory
The tilde is only meaningful in bash (or some other shell).
Try putting this in your .inputrc:
$if psql
set expand-tilde on
$endif
That
Tom Lane writes:
initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG
initdb --no-locale is the same as initdb --locale=C, for convenience.
I'm confused; what is the default behavior if you don't give any
switches to initdb?
Whatever is set in the environment -- which boils
Doug McNaught [EMAIL PROTECTED] writes:
Actually, the C standard says nothing about what algorithm should be
used for qsort(); it's simply supposed to be a fast in-memory sort.
The qsort() name is just a historical artifact.
In practice I believe qsort usually is a quicksort; it's just too
Doug McNaught wrote:
I think most vendors do a pretty good job. Don't forget, optimizing a
routine like that depends a lot on the cache size and behavior of the
CPU and other architecture-dependent stuff.
qsort() is a great sort for very random data, when data is mostly in the
correct
Andrew Sullivan [EMAIL PROTECTED] writes:
On Wed, Apr 03, 2002 at 10:23:41AM -0500, Tom Lane wrote:
But I can't see any reasonable way for configure to decide automatically
whether we should replace the system qsort. I think we'd have to put
a USE_PRIVATE_QSORT symbol definition into
...
I'm not sure I'm the only one, am I?
No, I was also blocked from Tom's mail a while ago. I have a static IP,
but my ISP's entire block of addresses made it on to the spam list Tom
uses, and the strategy of the list maintainers seems to be to maximize
the collateral damage to force me to
Justin Clift wrote:
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
Would it be an idea to have pg_dump append an ANALYZE; command to the end of
its dumps to assist newbies / inexperienced admins?
I do not think this is
Tom Lane writes:
mlw [EMAIL PROTECTED] writes:
(1) const or constant
(2) cacheable
(3) volatile
I was wondering about const for case 1, also. I think there is some
precedent for using const with this meaning in other programming
languages.
I think the meaning of const tends to be
Peter Eisentraut wrote:
Tom Lane writes:
mlw [EMAIL PROTECTED] writes:
(1) const or constant
(2) cacheable
(3) volatile
I was wondering about const for case 1, also. I think there is some
precedent for using const with this meaning in other programming
languages.
I
Thomas Lockhart [EMAIL PROTECTED] writes:
That said, I'd like to block some spam myself. I'd rather find a spam
list which doesn't already have me disallowed however...
In case it makes you feel better: my *own* address was on the 510sg list
for awhile last month. But I still use the list
mlw writes:
update mytable set foo=foo+1 where bar='xxx';
If that gets executed more than once at the same time by multiple instances of
postgresql. Will foo ever lose a count?
No, but if you run this in read committed isolation mode then you might
get into non-repeatable read type
mlw [EMAIL PROTECTED] writes:
Tom Lane wrote:
Sorry about that. I like 510sg's dnsbl list precisely because it's
aggressive, but sometimes it's too aggressive. I can whitelist you
if you have a stable IP address ... is 24.147.138.78 a permanently
assigned address, or not?
I wish I could
mlw writes:
A function, such as sin(x) could be considered constant for the result based on
value 'x'
It could also be considered deterministic, strict, cacheable,
mathematically sensible, real, pleasant, or good. ;-)
Out of those, I believe const is the worst term, because saying sin(x)
is
Hi Jan,
Jan Wieck wrote:
snip
The defaults after a restore should result in index scans
most of the time, resulting in some medium decent
performance. And PostgreSQL needs some frequent VACUUM
anyway, so after a while this problem solves itself for
Peter Eisentraut wrote:
mlw writes:
update mytable set foo=foo+1 where bar='xxx';
If that gets executed more than once at the same time by multiple instances of
postgresql. Will foo ever lose a count?
No, but if you run this in read committed isolation mode then you might
get
Peter Eisentraut wrote:
Tom Lane writes:
mlw [EMAIL PROTECTED] writes:
(1) const or constant
(2) cacheable
(3) volatile
I was wondering about const for case 1, also. I think there is some
precedent for using const with this meaning in other programming
languages.
I
Tom Lane writes:
It might be that Bruce's recent changes to elog levels allow a graceful
compromise about backend messages during initdb. I haven't looked, but
maybe initdb could run the backend with message level one notch higher
than LOG to suppress all the normal-case messages without
Martin Renters [EMAIL PROTECTED] writes:
It is also pretty unreasonable to think that any company is
going to switch providers because of one blacklist or somehow complain
to their ISP about the spammers the ISP is hosting without any more
detail than:
Blacklist X says you provide
mlw writes:
For each page hit, I do this:
update pagecounts set counter = counter + 1 where pagename = 'testpag.php'
Do I have to set a particular isolation level? Or does this not work in
general?
In read committed level, if the second update launches before the first
update is finished
Peter Eisentraut [EMAIL PROTECTED] writes:
It could also be considered deterministic, strict, cacheable,
mathematically sensible, real, pleasant, or good. ;-)
Out of those, I believe const is the worst term, because saying sin(x)
is a constant function sounds pretty wrong.
Yeah, that was my
Peter Eisentraut [EMAIL PROTECTED] writes:
I was thinking about handling this
within initdb, with a display like this:
The files belonging to this database system will be owned by user peter.
This user must also own the server process.
Locale settings: collate=en_US ctype=en_US [...]
Jan Wieck [EMAIL PROTECTED] writes:
... And PostgreSQL needs some frequent VACUUM
anyway, so after a while this problem solves itself for the
average user.
Yes, that's the key point for me too. Anyone who doesn't set up for
routine vacuums/analyzes is going to have
It occurs to me that we also need a better term for the overall concept.
cacheability has misled at least two people (that I can recall) into
thinking that we maintain some kind of function result cache --- which
is not true, and if it were true we'd need the term cacheable for
control parameters
Jessica Perry Hekman wrote:
On Tue, 2 Apr 2002, Barry Lind wrote:
Since both the JDBC and ODBC specs have essentially the same symantics
for this, I would hope this is done in the backend instead of both
interfaces.
The current plan seems to be to make changes in the backend and the
Tom Lane wrote:
It occurs to me that we also need a better term for the overall concept.
cacheability has misled at least two people (that I can recall) into
thinking that we maintain some kind of function result cache --- which
is not true, and if it were true we'd need the term cacheable
mlw [EMAIL PROTECTED] writes:
I'm not sure you answered my question. Let me put it to you like this:
Suppose I wanted to make a table of page counts, like this:
create table pagecounts (counter int4, pagename varchar)
For each page hit, I do this:
update pagecounts set counter = counter + 1
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
... And PostgreSQL needs some frequent VACUUM
anyway, so after a while this problem solves itself for the
average user.
Yes, that's the key point for me too. Anyone who doesn't set up for
routine vacuums/analyzes
BTW, I still suggest changing initdb to set message_level = FATAL rather
than /dev/null'ing the output. Having to use -d to learn anything at
all about the cause of an initdb-time failure is a pain in the neck.
This is a great idea. Certainly there are FATAL/PANIC messages during
initdb
Justin Clift [EMAIL PROTECTED] writes:
I agree adding an automatic background vacuum thread/process/something
will be really, really useful too.
Should we instead have this proposed automatic background something also
update the statistics every now and again?
Yes, I had always assumed
Tom Lane wrote:
LISTEN/NOTIFY is basically designed for invalidate-your-cache
arrangements (which is what led into this discussion originally, no?).
Why do you think so? Even if you are right and original design was
just for invalidate-your-cache arrangements, current implementation
has
Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
I agree adding an automatic background vacuum thread/process/something
will be really, really useful too.
Should we instead have this proposed automatic background something also
update the statistics every now and again?
Yes, I
Bruce Momjian [EMAIL PROTECTED] writes:
Does anyone know the ramifications of allowing SET to work in an aborted
transaction?
This is not an option.
The case that will definitely Not Work is SET variables whose setting
or checking requires database accesses. The new search_path variable
Mikhail Terekhov [EMAIL PROTECTED] writes:
Why do you think so? Even if you are right and original design was
just for invalidate-your-cache arrangements, current implementation
has much more functionality and can be used as a reliable message
transmission mechanism (we use it that way).
It
Tom Lane wrote:
Doug McNaught [EMAIL PROTECTED] writes:
Actually, the C standard says nothing about what algorithm should be
used for qsort(); it's simply supposed to be a fast in-memory sort.
The qsort() name is just a historical artifact.
In practice I believe qsort usually is a
On Wed, Apr 03, 2002 at 08:45:03AM -0800, Thomas Lockhart wrote:
...
I'm not sure I'm the only one, am I?
No, I was also blocked from Tom's mail a while ago. I have a static IP,
but my ISP's entire block of addresses made it on to the spam list Tom
uses, and the strategy of the list
Tom Lane writes:
The reason it works in read-committed mode is that the second guy to
arrive at the row will observe that the row has an update in progress;
will block waiting for the previous updater to commit or abort; and if
commit, will use the updated version of the row as the starting
Bruce Momjian writes:
There doesn't seem to be a way to turn off LOG without hiding almost
everything:
if (lev == LOG || lev == COMMERROR)
{
if (server_min_messages == LOG)
output_to_server = true;
else if (server_min_messages
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
The reason it works in read-committed mode is that the second guy to
arrive at the row will observe that the row has an update in progress;
will block waiting for the previous updater to commit or abort; and if
commit, will use the
Peter Eisentraut wrote:
Bruce Momjian writes:
There doesn't seem to be a way to turn off LOG without hiding almost
everything:
if (lev == LOG || lev == COMMERROR)
{
if (server_min_messages == LOG)
output_to_server = true;
else
Bruce Momjian writes:
Server levels are:
# debug5, debug4, debug3, debug2, debug1,
# info, notice, warning, error, log, fatal, panic
I don't recall log being so high. Didn't it use to be after info?
Certainly there should be a way to see only
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
It could also be considered deterministic, strict, cacheable,
mathematically sensible, real, pleasant, or good. ;-)
Out of those, I believe const is the worst term, because saying sin(x)
is a constant function sounds pretty
Peter Eisentraut wrote:
Bruce Momjian writes:
Server levels are:
# debug5, debug4, debug3, debug2, debug1,
# info, notice, warning, error, log, fatal, panic
I don't recall log being so high. Didn't it use to be after info?
Certainly there
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
To my mind, full SERIALIZABLE mode is the only approach that can be
explained in terms of simple notions like "you see only the data that
existed at time T".
There's another way. If the current value is different
Bruce Momjian wrote:
Jessica Perry Hekman wrote:
On Tue, 2 Apr 2002, Barry Lind wrote:
Since both the JDBC and ODBC specs have essentially the same symantics
for this, I would hope this is done in the backend instead of both
interfaces.
The current plan seems to be to make
For each page hit, I do this:
update pagecounts set counter = counter + 1 where pagename =
'testpag.php'
Do I have to set a particular isolation level? Or does this not work in
general?
In read committed level, if the second update launches before the first
update is finished
The current plan seems to be to make changes in the backend and the JDBC
interface, the bulk of the implementation being in the backend.
Yes, ODBC and JDBC need this, and I am sure psql folks will use it too,
not counting libpq and all the others.
I wasn't able to follow this
Bruce Momjian wrote:
The current plan seems to be to make changes in the backend and the JDBC
interface, the bulk of the implementation being in the backend.
Yes, ODBC and JDBC need this, and I am sure psql folks will use it too,
not counting libpq and all the others.
I
Hi,
I'm playing with the new schema functionality.
I login to a database as a user yamada.
There I created 2 schemas yamada and inoue.
By accident I made 2 tables with the same name
vs1 in both public and yamada schemas.
I can see the content of yamada.vs1 by the command
select * from vs1
but
Hiroshi Inoue wrote:
Why should the timeout be reset automatically ?
It doesn't need to be reset automatically, but the problem is that if
you are doing a timeout for single statement in a transaction, and that
statement aborts the transaction, the SET command after it to reset the
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Why should the timeout be reset automatically ?
It doesn't need to be reset automatically, but the problem is that if
you are doing a timeout for single statement in a transaction, and that
statement aborts the transaction, the SET
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Why should the timeout be reset automatically ?
It doesn't need to be reset automatically, but the problem is that if
you are doing a timeout for single statement in a transaction, and that
statement aborts
Bruce Momjian writes:
If you would prefer LOG down near INFO in the server message levels,
please post the idea and let's get some more comments from folks.
LOG should be below WARNING, in any case. Perhaps between NOTICE and
WARNING, but I'm not so sure about that.
--
Peter Eisentraut
Hiroshi Inoue [EMAIL PROTECTED] writes:
I can see the content of yamada.vs1 by the command
select * from vs1
but there seems to be no way to see the content of
public.vs1.
PUBLIC is a reserved keyword, so you have to do something like
select * from public.vs1;
if there is a vs1
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Why should the timeout be reset automatically ?
It doesn't need to be reset automatically, but the problem is that if
you are doing a timeout for single statement in a transaction,
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
If you would prefer LOG down near INFO in the server message levels,
please post the idea and let's get some more comments from folks.
LOG should be below WARNING, in any case. Perhaps between NOTICE and
WARNING, but I'm not
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
If you would prefer LOG down near INFO in the server message levels,
please post the idea and let's get some more comments from folks.
LOG should be below WARNING, in any case. Perhaps between NOTICE and
Hi all,
Some questions:
1. What is the difference between abstime and timestamp - they seem to
display equally...
2. Since int4 and abstime are binary compatible (ie int4::abstime works), is
there any serious problem with updating a pg_attribute row for an int4 and
changing it to and abstime?
Tom Lane wrote:
PUBLIC is a reserved keyword, so you have to do something like
select * from public.vs1;
if there is a vs1 hiding it in an earlier namespace in the search
path.
I've been vacillating about whether to choose another name for the
public namespace to avoid the need for
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I can see the content of yamada.vs1 by the command
select * from vs1
but there seems to be no way to see the content of
public.vs1.
PUBLIC is a reserved keyword, so you have to do something like
select * from
Tom Lane writes:
PUBLIC is a reserved keyword, so you have to do something like
select * from public.vs1;
if there is a vs1 hiding it in an earlier namespace in the search
path.
PUBLIC can be made less reserved easily. See patch below.
I've been vacillating about whether to choose
Gilles DAROLD wrote:
Hi Justin,
I have a new updated version of the Ora2Pg tool which correct many
problems and add some new features, could you or someone else update
the contrib directory.
(download at: http://www.samse.fr/GPL/ora2pg/ora2pg-1.8.tar.gz)
Thanks. CVS updated.
I also
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Nicolas Bazin wrote:
Here is the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Oliver Elphick wrote:
Checking
86 matches
Mail list logo
