Stephan Szabo [EMAIL PROTECTED] writes:
Improve speed of building of constraints during restore
Did we get consensus on what to do with this,
Not really, it was still up in the air I thought. However, the
discussion will become moot if we don't have an implementation
of the faster-checking
Bruce Momjian [EMAIL PROTECTED] writes:
By doing REINDEX always, we eliminate some folks are are happy
doing VACUUM FULL at night, because very few tuples are expired.
But if they have very few tuples expired, why do they need VACUUM FULL?
Seems to me that VACUUM FULL should be designed to
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are sufficient reason why not, even before you look at
the performance issues.
What are the atomicity problems of adding a create/expire xid to the
On Sat, Oct 04, 2003 at 14:24:40 -0400,
Tom Lane [EMAIL PROTECTED] wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
The following is still a problem in current cvs (as of 2 hours ago).
Not any more ;-)
Thanks. I tried it out and it is now working for me.
---(end
Greg Stark kirjutas P, 05.10.2003 kell 00:17:
I've never seen anyone use this feature, and I never seriously considered it
myself. It sort of has the feel of an antiquated feature that traded too much
flexibility and abstraction for raw performance on very slow disk hardware.
Read A
Do to a bug in pgtypeslin I've been experimenting with the day of week
stuff a little bit and I found that we do not agree with the output of
the cal command on older dates. I have no idea which one is correct:
mm=# select to_char('1000/01/01'::date,'D');
to_char
-
4
(1 row)
Thus we
Hannu Krosing wrote:
Greg Stark kirjutas P, 05.10.2003 kell 00:17:
I've never seen anyone use this feature, and I never seriously considered it
myself. It sort of has the feel of an antiquated feature that traded too much
flexibility and abstraction for raw performance on very slow disk
Michael Meskes writes:
mm=# select to_char('1000/01/01'::date,'D');
to_char
-
4
(1 row)
Thus we believe 1000/1/1 is a Wednesday. cal says:
Thus 1000/1/1 is a Monday. Is this a bug in cal? Or do we produce the
wrong output? Or do I simply misread the output?
cal takes into
Looks like it is caused by the switch to the Gregorian calendar in 1752,
when 11 days were chopped out of September ( in England and America -
elsewhere anywhere between Oct 1582 and early 20th century). A quick scan of
the code didn't show postgres taking account of this oddity, but I might
have
Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Improve speed of building of constraints during restore
Did we get consensus on what to do with this,
Not really, it was still up in the air I thought. However, the
discussion will become moot if we don't have an implementation
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
By doing REINDEX always, we eliminate some folks are are happy
doing VACUUM FULL at night, because very few tuples are expired.
But if they have very few tuples expired, why do they need VACUUM FULL?
Seems to me that VACUUM FULL
There was a discussion on -interfaces that might need more consideration.
http://archives.postgresql.org/pgsql-interfaces/2003-09/msg00026.php
Apparently, it has so far been an undocumented feature of libpq's function
PGfnumber (return column number from column name) that the column name
needs
Peter Eisentraut wrote:
There was a discussion on -interfaces that might need more consideration.
http://archives.postgresql.org/pgsql-interfaces/2003-09/msg00026.php
Apparently, it has so far been an undocumented feature of libpq's function
PGfnumber (return column number from column name)
Andrew Dunstan [EMAIL PROTECTED] writes:
Looks like it is caused by the switch to the Gregorian calendar in 1752,
when 11 days were chopped out of September ( in England and America -
elsewhere anywhere between Oct 1582 and early 20th century).
There was some discussion awhile back about
[ pgsql-interfaces added to cc list ]
Andreas Pflug [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
There was a discussion on -interfaces that might need more consideration.
http://archives.postgresql.org/pgsql-interfaces/2003-09/msg00026.php
Apparently, it has so far been an
Tom Lane wrote:
That was pretty much the argument that carried the day in the earlier
thread. However, I'm not sure how many people really use PQfnumber
(as opposed to hard-wiring assumptions about returned column numbers),
and it would seem that the intersection of those people with people who
On Sun, 2003-10-05 at 13:43, Andreas Pflug wrote:
Tom Lane wrote:
So other than the shortlived 6.2 release, releases before 6.5 had the
behavior Peter wants. I find it interesting that it took more than a
year for anyone to notice that the putative dequoting+downcasing logic
installed for
Peter Eisentraut wrote:
There was a discussion on -interfaces that might need more consideration.
http://archives.postgresql.org/pgsql-interfaces/2003-09/msg00026.php
Apparently, it has so far been an undocumented feature of libpq's function
PGfnumber (return column number from column
Andreas Pflug [EMAIL PROTECTED] writes:
If you change it, please give me a chance to code it version-aware so
quoting/non-quoting can be performed dependent on libpq in use.
If you want a run-time test, the most reliable way would be to directly
test what PQfnumber does --- for instance, make
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Is there a reason why it can't accecpt both formats?
Does it downcase FOO or not? You can't have it both ways.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Since this behavior was undocumented and no one had noticed it in the last
10 years, I think we can away with removing it.
I agree. I would never expect to add quotes to a C string to preserve
case (outside SQL), and the fact
On Sun, 5 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Improve speed of building of constraints during restore
Did we get consensus on what to do with this,
Not really, it was still up in the air I thought. However, the
discussion will become moot if we don't have
Stephan Szabo [EMAIL PROTECTED] writes:
On Sun, 5 Oct 2003, Tom Lane wrote:
Not really, it was still up in the air I thought. However, the
discussion will become moot if we don't have an implementation
of the faster-checking alternative to look at pretty soon. Do you
have something nearly
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Since this behavior was undocumented and no one had noticed it in the last
10 years, I think we can away with removing it.
I agree. I would never expect to add quotes to a C string to preserve
case
On Sat, Oct 04, 2003 at 11:53:49PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Imagine having to VACUUM FULL a huge
table. Not only it will take the lot required to do the VACUUM in the
heap itself, it will also have to rebuild all indexes from scratch.
A very large
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 05 October 2003 20:41
To: Tom Lane
Cc: Peter Eisentraut; PostgreSQL Development
Subject: Re: [HACKERS] PQfnumber and quoted identifiers
Strange no one complained about it until now. I suppose that
is
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 05 October 2003 20:41
To: Tom Lane
Cc: Peter Eisentraut; PostgreSQL Development
Subject: Re: [HACKERS] PQfnumber and quoted identifiers
Strange no one complained about it until
Stephan Szabo [EMAIL PROTECTED] writes:
It's not cleaned up, but yes. It appears to work for the simple tests I've
done and should fall back if the permissions don't work to do a single
query on both tables.
Here's my code-reviewed version of the patch. Anyone else want to take
a look?
I
Wow, that's a heap of code --- that's my only comment. :-)
---
Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
It's not cleaned up, but yes. It appears to work for the simple tests I've
done and should fall
Bruce Momjian [EMAIL PROTECTED] writes:
Wow, that's a heap of code --- that's my only comment. :-)
Most of it is pretty direct cribbing of code that already exists in
the other routines in ri_triggers.c, so it's not really completely
new code, just boilerplate.
regards,
Dear PostgreSQL masters,
I know this might look like a childish question and you
probably might have a good laugh over this but I
would like to learn how PostgreSQL works inside-out.
Could anyone please give me some pointers of where to start
in/from the source code?
I am grateful for any help.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Wow, that's a heap of code --- that's my only comment. :-)
Most of it is pretty direct cribbing of code that already exists in
the other routines in ri_triggers.c, so it's not really completely
new code, just boilerplate.
Oh, that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It is something we could clearly advertise as changing in 7.5.
I think assuming that advertising a planned change will accomplish much
is just fooling ourselves :-(. There'll be approximately the same
number of complaints either way,
Gevik Babakhani wrote:
Dear PostgreSQL masters,
I know this might look like a childish question and you
probably might have a good laugh over this but I
would like to learn how PostgreSQL works inside-out.
Could anyone please give me some pointers of where to start
in/from the source
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. We can add it to TODO. That is advertising the change.
I'd be inclined to put something in the SGML docs describing
PQfnumber(), also.
regards, tom lane
---(end of
On Sun, 5 Oct 2003, Bruce Momjian wrote:
Wow, that's a heap of code --- that's my only comment. :-)
And you reposted the *whole* patch for that?? *tsk* *tsk*
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
On Sun, 2003-10-05 at 17:21, Bruce Momjian wrote:
Sure, check out the developers web page. It has some basic outlines,
and an FAQ. After that, it is mostly digging. You will need an editor
that supports tags or some way to pull symbols out of the code, and
hopefully cross-references.
Alvaro Herrera wrote:
Yeah, I think that's exactly the important point. These days there's
not a lot of reason to do VACUUM FULL unless you have a major amount of
restructuring to do. I would once have favored maintaining two code
paths with two strategies, but now I doubt it's worth the
Neil Conway wrote:
On Sun, 2003-10-05 at 17:21, Bruce Momjian wrote:
Sure, check out the developers web page. It has some basic outlines,
and an FAQ. After that, it is mostly digging. You will need an editor
that supports tags or some way to pull symbols out of the code, and
hopefully
Marc G. Fournier wrote:
On Sun, 5 Oct 2003, Bruce Momjian wrote:
Wow, that's a heap of code --- that's my only comment. :-)
And you reposted the *whole* patch for that?? *tsk* *tsk*
Oops, sorry.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL
On Sun, 5 Oct 2003, Gevik Babakhani wrote:
Dear PostgreSQL masters,
I know this might look like a childish question and you
probably might have a good laugh over this but I
would like to learn how PostgreSQL works inside-out.
Could anyone please give me some pointers of where to start
Fixed.
Bruce Momjian writes:
This item has been added to the 7.4 open items list:
ftp://momjian.postgresql.org/pub/postgresql/open_items
---
Rod Taylor wrote:
-- Start of PGP signed section.
Below is output
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Looks like it is caused by the switch to the Gregorian calendar in 1752,
when 11 days were chopped out of September ( in England and America -
elsewhere anywhere between Oct 1582 and early 20th century).
There was some discussion
On Sun, 2003-10-05 at 17:45, Bruce Momjian wrote:
Neil Conway wrote:
Depending on what part of the source you're interested in, a book on
DBMS implementation might also be useful, such as
Wow, $100.
Well, it's a CS textbook -- I have several textbooks this semester that
are $100.
Does
Is there any reason other than historical that the System Views setup
isn't a separate script fed to postgres by initdb, like, say, the
information schema file? If there isn't a good reason should we unwire
it as part of moving to a C version of initdb?
cheers
andrew
On Sun, Oct 05, 2003 at 11:15:56PM +0200, Gevik Babakhani wrote:
Gevik,
I know this might look like a childish question and you
probably might have a good laugh over this but I
would like to learn how PostgreSQL works inside-out.
Could anyone please give me some pointers of where to start
Neil Conway wrote:
On Sun, 2003-10-05 at 17:45, Bruce Momjian wrote:
Neil Conway wrote:
Depending on what part of the source you're interested in, a book on
DBMS implementation might also be useful, such as
Wow, $100.
Well, it's a CS textbook -- I have several textbooks this
To be clear, this is not about \N as the default external
representation for NULL, I'm talking about a string consisting of the
two characters backslash and uppercase-N.
CREATE TABLE nonu (tx text NOT NULL);
INSERT INTO nonu VALUES ('\\N');
SELECT * FROM nonu;
COPY nonu TO stdout;
This correctly
On Sun, 5 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I wasn't sure what to do about some of the spi error conditions. For many
of them I'm just returning false now so that it will try the other
mechanism in case that might work. I'm not really sure if that's worth
Manfred Koizar [EMAIL PROTECTED] writes:
To be clear, this is not about \N as the default external
representation for NULL, I'm talking about a string consisting of the
two characters backslash and uppercase-N.
Now that I look at it, this must have been broken since the beginning of
time, or
[EMAIL PROTECTED] (Peter Eisentraut - PostgreSQL) writes:
When revoking privileges from the owner, don't revoke the grant options,
to avoid recursively revoking everything from everyone.
So an owner can never revoke his own grant options? That seems
reasonable offhand, and
Bruce Momjian [EMAIL PROTECTED] writes:
Oh, that makes me feel better. Do we have timings for this code?
This is just a single data point, but I made a table of 1 million
rows containing just the int4 primary key column (values 0-1million
in a somewhat random order). Then I copied the same
Tom Lane wrote:
It'd clearly be worth our while to mention boosting sort_mem as a
helpful thing to do during bulk data load --- it should speed up
btree index creation too. I don't think that tip appears anywhere
in the docs at the moment.
Added recently, see last sentence:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
It'd clearly be worth our while to mention boosting sort_mem as a
helpful thing to do during bulk data load --- it should speed up
btree index creation too. I don't think that tip appears anywhere
in the docs at the moment.
Added
I have solved my restore problem by editing (the relevant part of) the
dump (:%s/^IN^I/^IN ^I/), a one-off solution g
Anyway, thanks for your investigation.
On Sun, 05 Oct 2003 19:12:50 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
it seems we have to compare the null representation string to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
It'd clearly be worth our while to mention boosting sort_mem as a
helpful thing to do during bulk data load --- it should speed up
btree index creation too. I don't think that tip appears anywhere
in the docs at
Do to a bug in pgtypeslin I've been experimenting with the day of week
stuff a little bit and I found that we do not agree with the output of
the cal command on older dates. I have no idea which one is correct:
mm=# select to_char('1000/01/01'::date,'D');
to_char
-
4
(1 row)
Thus we
On Fri, Aug 08, 2003 at 03:49:36PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended. (Gerry Pourwelle)
Stephan Szabo [EMAIL PROTECTED] writes:
It's probably okay to give the no such key error in the delete case
(at some point it'd be nice to make it give serialization failure, but
that might take alot more work than is warrented at this time for 7.4)
Per prior discussion, I think the no such
Andrew Dunstan [EMAIL PROTECTED] writes:
Is there any reason other than historical that the System Views setup
isn't a separate script fed to postgres by initdb, like, say, the
information schema file? If there isn't a good reason should we unwire
it as part of moving to a C version of
Hi guys,
During a pg_dump, does the extra_float_digits option only affect the
COPY data, or could it possibly also affect column defaults, view
definitions, etc?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
On Sun, 2003-10-05 at 19:58, Tom Lane wrote:
That's a fairly useless place to put it, though, since someone would
only think to look at sort_mem if they already had a clue. It should
be mentioned under bulk data load (in performance tips chapter)
Attached is a doc patch that does this. The
Neil Conway [EMAIL PROTECTED] writes:
(BTW, is there a reason the docs consistently call them B-tree
indexes, not B+-tree indexes?)
The latter might be technically more correct, but most people are going
to think it's a typo. I think B-tree is fine for the purposes of our docs.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think that's not happening, conditionally or otherwise. The atomicity
problems alone are sufficient reason why not, even before you look at
the performance issues.
What are the atomicity problems of adding a
64 matches
Mail list logo
