Am Mittwoch, den 26.07.2006, 16:58 -0400 schrieb Tom Lane:
> Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> This is a cute hack, but it does only a small part of what I think the
> spec says.
Thank you for compliment.
>
> In the first place, the SQL syntax is pretty clear that you can combine
> s
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> The attached patch requires the new row to fit, and 10% to be free on
> the page. Would someone test that?
This is another solution for the same purpose. We can avoid to call
PageIndexMultiDelete() to remove only one tuple. _bt_split() becomes
to ignor
Bruce Momjian wrote:
This patch for libpq allows you to enter an LDAP URL in
pg_service.conf.
The URL will be queried and the resulting string(s) parsed for
keyword = value connection options.
>>>
>>> I have heavily modified your patch to be clearer. Please
>>> review the
>>>
Include here a prototype patch that implements pg_switch_xlog() in line
with earlier discussions about how this should be implemented.
This patch implements
- separate function for manual xlog switch
- internals to allow pg_stop_backup() to perform auto log switching
Patch applies cleanly to cvst
Patch applied. Thanks.
---
Albe Laurenz wrote:
> Bruce Momjian wrote:
> This patch for libpq allows you to enter an LDAP URL in
> pg_service.conf.
> The URL will be queried and the resulting string(s) parsed
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> ... We could provide the mixed update syntax and leave the
> typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form, because you ca
Tom Lane wrote:
> much anything that can generate a row. The patch as you have it
> provides nothing more than syntactic sugar for something people can do
> anyway. The reason people want this syntax is that they expect to be
> able to write, say,
>
> UPDATE mytab SET (foo, bar, baz) =
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> UPDATE mytab SET (foo, bar, baz) =
>> (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
> That UPDATE example is interesting because I remember when using
> Informix that I had to do a separate SELECT statement for each
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> UPDATE mytab SET (foo, bar, baz) =
> >> (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
>
> > That UPDATE example is interesting because I remember when using
> > Informix that I had to do a separ
Joachim,
I checked your improvement and fix some problem with following scenario:
shared_buffers = 3301
START
share_buffers = 333.39
HUP
share_buffers requires integer value. Skip configuration file
#share_buffers = 3301
HUP
silent - no message
I performed some cleanup in my code as well.
Joshua Reich wrote:
Ok. Here is a diff taken from the top of the contrib tree. I have
suppressed the notices in both the cube and earthdistance packages.
All tests pass.
Doesn't this contain parts that have been already applied? It looks to
me like you need to do a cvs update (and then a s
You are correct.
Patch against the latest HEAD attached.
Josh
Andrew Dunstan wrote:
Joshua Reich wrote:
Ok. Here is a diff taken from the top of the contrib tree. I have
suppressed the notices in both the cube and earthdistance packages.
All tests pass.
Doesn't this contain parts that h
Ok. Here is a diff taken from the top of the contrib tree. I have
suppressed the notices in both the cube and earthdistance packages. All
tests pass.
Josh
Tom Lane wrote:
Joshua Reich <[EMAIL PROTECTED]> writes:
I'm not sure exactly what to do here. I tried simply doing
CREATE TYPE cube;
B
On Jul 27, 2006, at 7:30 AM, Tom Lane wrote:
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in a
On Jul 26, 2006, at 4:29 PM, Hannu Krosing wrote:
Well the desire for it comes from a very well established need
for dealing
with extremely large tales with relatively small hot spots. The
basic problem
being that currently the cost of vacuum is proportional to the
size of the
table rather t
There is also an issue with PPC processors with +/-0 in the cube test:
*** ./expected/cube.out Thu Jul 27 05:23:14 2006
--- ./results/cube.out Thu Jul 27 05:43:21 2006
***
*** 144,150
SELECT '-1e-700'::cube AS cube;
cube
--
! (0)
(1 row)
SELECT '1234567890123456'
On Wednesday 26 July 2006 14:27, Darcy Buskermolen wrote:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we would do it. T
Tom Lane wrote:
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form
On Jul 26, 2006, at 10:29 AM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point
here is
that the existing vacuum does not rely on re-computing index keys; all
Joshua Reich wrote:
You are correct.
Patch against the latest HEAD attached.
I have applied this and made an attempt to fix cube/expected/cube_1.out
- we will still need to keep an eye on the various cube tests.
cheers
andrew
---(end of broadcast)-
On Tue, 2006-07-18 at 16:36 -0700, Marc Munro wrote:
> The attached patch provides add-ins with the means to register for
> shared memory and LWLocks. This greatly improves the ease with which
> shared memory may be used from add-ins, while blah blah blah
I have tried to be patient but this i
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Some small clean-up of the patch...
> + implementing the Tom's idea of minimizing the copying of the data inside
> advance_transition_function by using the temporary FunctionCallInfoData
> (now the computed arguments of the aggregates are putted dir
Marc Munro <[EMAIL PROTECTED]> writes:
>> The attached patch provides add-ins with the means to register for
>> shared memory and LWLocks. This greatly improves the ease with which
>> shared memory may be used from add-ins, while blah blah blah
> I have tried to be patient but this is my firs
Jim Nasby <[EMAIL PROTECTED]> writes:
> Even if we stopped right there it would still be a huge win in many (most?)
> cases. How often do the indexes on a table comprise even 50% of the table's
> size?
I would say they're usually roughly comparable actually. It depends on how
wide your table
Jim Nasby wrote:
> On Jul 27, 2006, at 7:30 AM, Tom Lane wrote:
> > Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> >> ... We could provide the mixed update syntax and leave the
> >> typed row value expression for the next release. Do you agree?
> >
> > I don't really see the point --- the patch won'
Hi folks,
As I said on -PATCHES, I've been working on an utility to get
a b-tree index information. I'm happy to introduce
my new functions to you.
pgstattuple module provides a `pgstatindex()`, and other small
functions, which allow you to get b-tree internal information.
I believe this module w
26 matches
Mail list logo
