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:
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
Gaet
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
-
> 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 an
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
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 cop
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 A
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
sh
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
---
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 su
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.
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
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
> >> i
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.
>
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:
sort_me
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 d
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
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
[EMAI
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 unregis
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
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.
regard
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 f
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?
>
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 somethin
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 d
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 implem
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-checkin
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, b
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 r
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 wr
30 matches
Mail list logo
