Tom Lane wrote:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
there is a chance to add a STEP clause to the FOR statement in plpgsql?
This is not free: it'd require making STEP a reserved word (at least
within plpgsql) which is contrary to spec. I think you need to make
a pretty good
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> there is a chance to add a STEP clause to the FOR statement in plpgsql?
This is not free: it'd require making STEP a reserved word (at least
within plpgsql) which is contrary to spec. I think you need to make
a pretty good case why the value of the f
Hi,
there is a chance to add a STEP clause to the FOR statement in plpgsql?
something like
FOR i IN 1..100 STEP 2 LOOP
END LOOP
the STEP value must be a positive value because of the effect of the
REVERSE clause...
i think it's just a matter of fixing gram.y, plpgsql.h (to add
another PLpgSQ
Robert Treat <[EMAIL PROTECTED]> writes:
> If Larry can do the work of getting details added into the stats views, I'm
> comfortable just setting all of the logging to debug1 and leaving it at that.
> I still could see the idea of having a guc for an autovacuum specific log
> control; I could see
On Friday 28 April 2006 19:06, Bruce Momjian wrote:
> I am thinking, what do we want to show by default about autovacuum in
> the server logs. What if we output a line the first time autovacuum
> runs successfully on server start?
>
If Larry can do the work of getting details added into the stats
I am thinking, what do we want to show by default about autovacuum in
the server logs. What if we output a line the first time autovacuum
runs successfully on server start?
---
Bruce Momjian wrote:
> Robert Treat wrote:
> >
I was looking at what it'd take to handle attaching an error cursor
to the message about "column "foo" must appear in the GROUP BY clause or
be used in an aggregate function", as per recent discussion here:
http://archives.postgresql.org/pgsql-sql/2006-04/msg00206.php
While we've now got the parse
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
Kris Jurka wrote:
Anyway the test exits with
Stuck spinlock (80618e9) detected at ./s_lock.c:355.
on a linux gcc build this exits with
Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.
This seems like a different problem, no? The patch I
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c
can be compiled standalone with -DS_LOCK_TEST
To get the test to compile I had to link in tas.o as the attached patch
shows. Unfortunately this doesn't work for platforms th
Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
> > > Martijn van Oosterhout writes:
> > >> You know, rather than adding new columns to pg_class, why not extend
> > >> the stats collector to collect this information.
> >
> > That sounds doable. And
Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
>>> Martijn van Oosterhout writes:
You know, rather than adding new columns to pg_class, why not
extend the stats collector to collect this information.
>>
>> That sounds doable. And a lot l
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
What platform is that? (OS rev, architecture and word size)? I tested the
changes I submitted on Solaris 10 amd64.
$ uname -a
SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc
$ cc -V
cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-09 2003/05
On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
> > Martijn van Oosterhout writes:
> >> You know, rather than adding new columns to pg_class, why not extend
> >> the stats collector to collect this information.
>
> That sounds doable. And a lot less scary for me (as a relative
>
Tom Lane wrote:
> Martijn van Oosterhout writes:
>> You know, rather than adding new columns to pg_class, why not extend
>> the stats collector to collect this information.
>
> +1
>
> regards, tom lane
That sounds doable. And a lot less scary for me (as a relative noobie)
Martijn van Oosterhout writes:
> You know, rather than adding new columns to pg_class, why not extend
> the stats collector to collect this information.
+1
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched
Robert Treat <[EMAIL PROTECTED]> writes:
> The first is to add a column(s) to pg_class to hold last vaccum/analyze time
> for each table.
I really don't want us to do that. relpages/reltuples are already an
ugly wart. The fundamental problem with this (or indeed any of the
various proposals for
On Fri, Apr 28, 2006 at 04:08:41PM -0400, Robert Treat wrote:
> The first is to add a column(s) to pg_class to hold last vaccum/analyze time
> for each table. The upsides would be that this puts the information in a
> readily accessable place that can be viewed from third party tools and
> quer
Robert Treat wrote:
> On Friday 28 April 2006 12:09, Larry Rosenman wrote:
>> Larry Rosenman wrote:
>>> Simon Riggs wrote:
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> I'd like to see a more concrete definition of what we
>> w
On Friday 28 April 2006 12:09, Larry Rosenman wrote:
> Larry Rosenman wrote:
> > Simon Riggs wrote:
> >> On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
> >>> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> I'd like to see a more concrete definition of what we
> want Autovacuum to outpu
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So for you it would certainly help a lot to be able to vacuum the first
> > X pages of the big table, stop, release locks, create new transaction,
> > continue with the next X pages, lather, rinse, repeat.
>
> > This is perfectly doa
On 4/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Brandon Black" <[EMAIL PROTECTED]> writes:
> I was wondering (for planning purposes) if anyone knew the status of
> constraint exclusions moving up to query runtime and working for
> joins.
The latter, done; the former, not on the radar screen IMH
Kris Jurka wrote:
> Bruce Momjian wrote:
> > Log Message:
> > ---
> > Modify Solaris compiler build rules to use the cpp preprocessor, the the
> > x86 file.
> >
>
> Well it compiles now, but it doesn't seem to work:
>
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2006-04-28%201
"Takes clustering into account" means nothing. We don't need that. Any
such consideration would be handled by the AM-specific amcostestimate
function.
Ok, I see. Sorry for misunderstanding. I thought that planner use that.
--
Teodor Sigaev E-mail: [EMAIL PROT
Larry Rosenman wrote:
> Simon Riggs wrote:
>> On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
>>> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
>>>
>>> autovacuum_verbosity
>>
>> Should
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Huh? Why two? Either you are allowed to cluster on indexes of this
>> type, or you're not. I don't see the point of any other distinction.
> amclusterable - as you suggest: Does cluster command something or not?
This is what we need.
> amclustered
ok. amskipcheck?
Oh, I was thinking of having VACUUM put the heap tuple count into the
struct and then amvacuumcleanup could copy it over to the index tuple
count. A "skipcheck" flag only solves the cosmetic problem of not
getting the warning, it doesn't fix things so that the correct count
e
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> We could probably fix that by adding it to the stats structs that are
>> passed around during VACUUM. I'd rather not hardwire a GIN special case
>> in vacuum.c as per your "quick hack".
> ok. amskipcheck?
Oh, I was thinking of having VACUUM put the
We could probably fix that by adding it to the stats structs that are
passed around during VACUUM. I'd rather not hardwire a GIN special case
in vacuum.c as per your "quick hack".
ok. amskipcheck?
Here I think it would be best to add an indclusterable column to pg_am.
GIN is _always_ clust
On Fri, Apr 28, 2006 at 10:14:09AM -0400, Tom Lane wrote:
> Here I think it would be best to add an indclusterable column to pg_am.
> Actually, does clustering on *any* current index type except btree make
> sense? None of them have semantically interesting index ordering
> AFAIR, so maybe we shou
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> One problem: ambulkdelete hasn't any access to heap or heap's statistics
> (num_tuples in scan_index() and vacuum_index() in vacuum.c). So, ambulkdelete
> can't set stats->num_index_tuples equal to num_tuples.
We could probably fix that by adding it to
There's a definitional issue here, which is what does it mean to be
counting index tuples. I think GIN could bypass the VACUUM error check
by always returning the heap tuple count as its index tuple count. This
One problem: ambulkdelete hasn't any access to heap or heap's statistics
(num_tupl
Hello
I am stupid. 1) I don't call function.
I am sorry
Regards
Pavel Stehule
_
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
---(end of broadcast)---
TIP 2:
Hello
This code run without error, but do nothing
drop role x;
create role x;
create or replace function foo() returns void as $$
begin
grant root to x;
end;
$$ language plpgsql;
\dg x
revoke root from x;
postgres=# postgres=# DROP ROLE
postgres=# CREATE ROLE
postgres=# postgres$# postgres$# p
33 matches
Mail list logo
