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 con
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.
---
Ni
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
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 broadcast)
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.
re
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 th
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.
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 D
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 update
11 matches
Mail list logo
