What's with this patch?
I do not see it in unapplied patches list, neither it was commited...
What we have now in CVS is not a good thing.
On 4/10/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Here is new version that adds following changes:
4. Function is now strict, per discussion.
5.
Does this eliminate problems with using a large number of tablespaces?
---
Tom Lane wrote:
Log Message:
---
Some further performance tweaks for planning large inheritance trees that
are mostly excluded by
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Thanks, added to queue.
---
Nikolay Samokhvalov wrote:
What's with this patch?
I do not see it in unapplied patches list, neither it was commited...
What we have now in CVS is not a good thing.
On 4/10/07, Nikolay
Patch applied by Peter. Thanks.
---
Joachim Wieland wrote:
On Mon, Apr 02, 2007 at 07:25:46PM -0400, Bruce Momjian wrote:
I assume this patch is not ready for 8.3, so I added a URL to the TODO
list for it.
I have
Tom Lane wrote:
So I think attaching a precedence to the GENERATED keyword is dangerous.
Especially when we have a good workaround which would just require use
of () around certain postfix-operator expressions.
cheers
andrew
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
Does this eliminate problems with using a large number of tablespaces?
No, it doesn't have anything particular to do with tablespaces.
It gets rid of some bottlenecks that become noticeable with a
large number of child tables.
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
So I think attaching a precedence to the GENERATED keyword is dangerous.
Especially when we have a good workaround which would just require use
of () around certain postfix-operator expressions.
Yeah, I'm leaning to the idea that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Does this eliminate problems with using a large number of tablespaces?
No, it doesn't have anything particular to do with tablespaces.
It gets rid of some bottlenecks that become noticeable with a
large number of child tables.
Yes,
Hi,
I don't insist the name and the default of the GUC parameter. I'm
afraid wal_fullpage_optimization = on (default) makes some confusion
because the default behavior becomes a bit different on WAL itself.
I'd like to have some more opinion on this.
Zeugswetter Andreas ADI SD wrote:
With
Heikki Linnakangas wrote:
The way you update the DSM is quite interesting. When a page is dirtied,
the BM_DSM_DIRTY flag is set in the buffer descriptor. The corresponding
bit in the DSM is set lazily in FlushBuffer whenever BM_DSM_DIRTY is
set. That's a clever way to avoid contention on
11 matches
Mail list logo
