As you can see, we don't have many open items left.
---
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at
Patch applied. Thanks.
---
Neil Conway wrote:
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
Bruce Momjian wrote:
Wow, that's a heap of code --- that's my only comment. :-)
Not really.
I'm not sure what conditions could possibley cause SPI_prepare to return
NULL, but it'd be certainly better to check that. Other than that, looks
good to me.
Jan
Jan Wieck [EMAIL PROTECTED] writes:
I'm not sure what conditions could possibley cause SPI_prepare to return
NULL, but it'd be certainly better to check that.
Good thought. I was looking at the other SPI_prepare calls in
ri_triggers.c, which don't check for NULL either, but clearly they
Jan Wieck [EMAIL PROTECTED] writes:
Does an ANALYZE run between index creation and bulk FK checking improve
planning?
It almost certainly would, but I was assuming we had to consider this in
the context of loading existing dump files. We could think about having
pg_dump emit an automatic
Tom Lane wrote:
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
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Does an ANALYZE run between index creation and bulk FK checking improve
planning?
It almost certainly would, but I was assuming we had to consider this in
the context of loading existing dump files. We could think about having
pg_dump
It almost certainly would, but I was assuming we had to consider this in
the context of loading existing dump files. We could think about having
pg_dump emit an automatic ANALYZE after the data loading step in the
future though.
Rather than running ANALYZE, how about simply dumping out and
Rod Taylor [EMAIL PROTECTED] writes:
Rather than running ANALYZE, how about simply dumping out and restoring
current statistics?
Nope. That would assume that the stats are the same across revisions.
Not to mention requiring superuser privileges.
regards, tom lane
Bruce Momjian wrote:
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
On the same folder there is: PITR_20020822_02.gz
tell me that we are near to have it :-)
Regards
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
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
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
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,
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
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
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, 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
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
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
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
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.
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
---
Fix REVOKE ALL ON FUNCTION error when removing owner permissions
Improve speed of building of constraints
On Sun, 5 Oct 2003, Bruce Momjian wrote:
Improve speed of building of constraints during restore
Did we get consensus on what to do with this, whether we're doing
only the superuser option to not check, only speeding up fk constraint
checks by using a statement instead of the repeated calls,
Bruce Momjian [EMAIL PROTECTED] writes:
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
A couple things you don't have there:
* Tuple visibility rules for triggers and rules fired by RI actions
(I'm now of the opinion that the visibility patch I put in a few days
ago is
Both added. Thanks.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
A couple things you don't have there:
* Tuple visibility rules for
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
---
Fix REVOKE ALL ON FUNCTION error when removing owner permissions
Fix plpgsql handling of boolean tests on
33 matches
Mail list logo
