Andreas Seltenreich <[EMAIL PROTECTED]> writes:
> I think there's a call to pgstat_count_index_scan missing in GIN.
> Currently, the idx_scan column of pg_stat_*_indexes is stuck at zero
> for GIN indexes.
> Patch attached.
Looks correct to me --- applied.
regards, tom lan
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether
> old and new tuples were supplied rather than blindly setting them
> according to the event type. Per discussion in pgsql-hackers.
Looks good, applied.
regards,
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Docs and regression tests attached.
I've applied the regression tests (with a few additions), but I'm
feeling dissatisfied with this approach to documenting VALUES.
It seems to be mostly missing the point about VALUES being usable
whereever SELECT is. I'
On Aug 3, 2006, at 23:58 , Tom Lane wrote:
Should we give VALUES its own reference page? That doesn't quite
seem helpful either.
I think we should go for a separate reference page, as VALUES appears
to be expanding quite a bit. Up till now I've thought of VALUES only
in conjunction with
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Here is a patch to collect statistics of LWLocks.
This seems fairly invasive, as well as confused about whether it's an
#ifdef'able thing or not. You can't have system views and pg_proc
entries conditional on a compile-time #ifdef, so in a default bu
Simon Riggs <[EMAIL PROTECTED]> writes:
> WIP archive_timeout.
> All we need to do is add LWLock support to archiver.
> Thoughts/ideas/hints welcome.
Hint: this isn't the archiver's problem, and so you don't need to get
the archiver involved in the solution. I'd suggest bgwriter as a
reasonably a
On Thu, 2006-08-03 at 13:38 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > WIP archive_timeout.
> > All we need to do is add LWLock support to archiver.
> > Thoughts/ideas/hints welcome.
>
> Hint: this isn't the archiver's problem, and so you don't need to get
> the archiver
On Thu, Aug 03, 2006 at 12:05:23PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether
> > old and new tuples were supplied rather than blindly setting them
> > according to the event type. Per discussion in pgsq
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Thanks. Alvaro made the following suggestion but didn't copy the
> list -- shall I do what he suggested and submit the changes as
> another patch?
> Alvaro Herrera wrote:
>> I'd add an Assert() on the second hunk to make sure newtuple is only set
>> in U
"Joachim Wieland" <[EMAIL PROTECTED]> writes:
> Zdenek Kotala sent in regression tests for SET a few days ago which got
> turned down. I think however that the idea has merit and that only his
> implementation was not useful. Attached is another regression test script
> that executes some SET / SET
On Thu, 3 Aug 2006, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Docs and regression tests attached.
>
> I've applied the regression tests (with a few additions), but I'm
> feeling dissatisfied with this approach to documenting VALUES.
> It seems to be mostly missing the point ab
On Fri, 4 Aug 2006, Michael Glaesemann wrote:
> On Aug 3, 2006, at 23:58 , Tom Lane wrote:
>
>
> > Should we give VALUES its own reference page? That doesn't quite
> > seem helpful either.
> >
>
> I think we should go for a separate reference page, as VALUES appears
> to be expanding quite a bit.
On Aug 4, 2006, at 9:42 , Gavin Sherry wrote:
... with update? I associate it very closely with INSERT. After all,
INSERT is the only statement where we've had VALUES as part of the
grammar.
Of course! Thanks for catching the glitch. I must have a bad RAM chip.
Michael Glaesemann
grzm seespo
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Fri, 4 Aug 2006, Michael Glaesemann wrote:
>> On Aug 3, 2006, at 23:58 , Tom Lane wrote:
>>> Should we give VALUES its own reference page? That doesn't quite
>>> seem helpful either.
>>
>> I think we should go for a separate reference page, as VALUES
Good point. One question: are we happy calling this a 'VALUES list'? It's
better than a 'table value constructor'. I took the lead from a comment in
the
source.
table value constructor is name from ANSI. All people wiil find t.v.c., not
values list. I vote table value constructor.
Regar
15 matches
Mail list logo
