2007/7/3, Gregory Stark <[EMAIL PROTECTED]>:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> while not just a new rekind indicating this is a template and not and
> actual table. and using that template for creating the actual tables?
For precisely the reason stated upthread. That would mean cr
> How about a new relkind which causes the table to be located in
> PGDATA/base//pg_temp_/
> So each backend can have its own copy of the table with the same
> relfilenode; there's no need for extra catalog entries.
Uh-huh. And what do you do with relpages, reltuples, relfrozenxid, and
pg_stati
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
Well, with autovac defaulting to ON in 8.3, that's certainly obsolete
text now.
Is there a reason to say anything b
Joshua D. Drake wrote:
> Tom Lane wrote:
> >"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >>http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
> >
> >Well, with autovac defaulting to ON in 8.3, that's certainly obsolete
> >text now.
> >
> >Is there a reason to say anything beyo
Tom Lane wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
Well, with autovac defaulting to ON in 8.3, that's certainly obsolete
text now.
Is there a reason to say anything beyond "use autovac"?
Did we change the defau
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
Well, with autovac defaulting to ON in 8.3, that's certainly obsolete
text now.
Is there a reason to say anything beyond "use autovac"?
regards, tom lane
On Monday 02 July 2007 17:52, Jim C. Nasby wrote:
> From
> http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
>
> "Recommended practice for most sites is to schedule a database-wide
> VACUUM once a day at a low-usage time of day, supplemented by more
> frequent vacuuming of he
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> I rather doubt that. The most likely implementation would involve
>> cloning a "template" entry into pg_class.
> How about a new relkind which causes the table to be located in
> PGDATA/base//pg_temp_/
> So each backend can have i
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> while not just a new rekind indicating this is a template and not and
> actual table. and using that template for creating the actual tables?
For precisely the reason stated upthread. That would mean creating and
deleting catalog entries for every t
On 7/3/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Tom Lane escribió:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > I've often thought that having global temp tables would be a really
> > good idea, since it would drastically reduce the need to vacuum
> > catalog tables,
>
> I rather doubt that.
Oleg Bartunov wrote:
> On Wed, 20 Jun 2007, Bruce Momjian wrote:
> >>
> >> We need to decide if we need oids as user-visible argument. I don't see
> >> any value, probably Teodor think other way.
> >
> > This is a good time to clean up the API because there are going to be
> > user-visible changes
Tom Lane escribió:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > I've often thought that having global temp tables would be a really
> > good idea, since it would drastically reduce the need to vacuum
> > catalog tables,
>
> I rather doubt that. The most likely implementation would involve
> cl
From
http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
"Recommended practice for most sites is to schedule a database-wide
VACUUM once a day at a low-usage time of day, supplemented by more
frequent vacuuming of heavily-updated tables if necessary. (Some
installations with e
On Tuesday 26 June 2007 18:05, Tom Lane wrote:
> Log Message:
> ---
> Fix PGXS conventions so that extensions can be built against Postgres
> installations whose pg_config program does not appear first in the PATH.
> Per gripe from Eddie Stanley and subsequent discussions with Fabien Coelho
On Mon, Jul 02, 2007 at 10:44:55AM -0700, Eric wrote:
> I guess you can also get this before writing code from
>
> select typbyval from pg_type where typname='mytype'
Note that the flag might not be constant. For example int8 is not byval
currently whereas it could be on a 64-bit architecture. Ho
Greg Smith <[EMAIL PROTECTED]> writes:
> On Mon, 2 Jul 2007, Tom Lane wrote:
>>> # wal_buffers = 1MB
>> Is there really evidence in favor of such a high setting for this,
>> either?
> I noticed consistant improvements in throughput on pgbench results with
> lots of clients going from the default
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Per reports from Michael Fuhr and Jon Lapham --- it's a bit surprising
> we have not seen more reports, actually.
Oh, fwiw I've seen this. I stop and start postmasters so often I just assumed
something wasn't getting cleaned up perfectly. The last time wa
I wrote:
> I'm going to generate a smaller test program showing this and file
> a bug report at Red Hat.
Filed as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246509
in case anyone wants to track it. (I suspect the Red Hat kernel guys
will just bounce it upstream, but that's their call no
I guess you can also get this before writing code from
select typbyval from pg_type where typname='mytype'
...thanks again.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Mon, 2 Jul 2007, Tom Lane wrote:
# wal_buffers = 1MB
Is there really evidence in favor of such a high setting for this,
either?
I noticed consistant improvements in throughput on pgbench results with
lots of clients going from the default to 256KB, flatlining above that; it
seemed suffic
It's a plain old Linux kernel bug: it returns EIDRM when it really ought
to say EINVAL, and apparently always has. The surprising part is really
that we've not seen it many times before.
Kudos to Michael Fuhr for thinking to write a test program investigating
whether randomly-chosen IDs would yie
I
2007/7/2, Tom Lane <[EMAIL PROTECTED]>:
Jim Nasby <[EMAIL PROTECTED]> writes:
> I've often thought that having global temp tables would be a really
> good idea, since it would drastically reduce the need to vacuum
> catalog tables,
I rather doubt that. The most likely implementation would in
On Fri, 2007-06-29 at 11:13 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-06-28 at 20:23 -0400, Tom Lane wrote:
> >> The methodology I suggested earlier (involving tracking LSN only at the
> >> level of pg_clog pages) isn't going to make that work, unless you
>
On Mon, 2007-07-02 at 17:41 +0100, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > 2) Charge-back accounting. Keep track by userid, user group, time of
> > access etc of all accesses to the system, so we can provide chargeback
> > facilities to users. You can put your chargi
Tom Lane wrote:
(change requires restart): this phrase appears over 20 times in the
notes. This is enough times to be really repetitive and take up a lot
of scrolling space, while not actually covering all startup-time
parameters. We should either (a) remove all such notes and rely on
docs,
Gregory Stark <[EMAIL PROTECTED]> writes:
> Sure, but I think Tom's question is how do you get from the plugin to wherever
> you want this data to be? There's not much you can do with the data at that
> point. You would end up having to reconstruct the entire stats collector
> infrastructure to shi
Jim Nasby <[EMAIL PROTECTED]> writes:
> I've often thought that having global temp tables would be a really
> good idea, since it would drastically reduce the need to vacuum
> catalog tables,
I rather doubt that. The most likely implementation would involve
cloning a "template" entry into pg_
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> 2) Charge-back accounting. Keep track by userid, user group, time of
> access etc of all accesses to the system, so we can provide chargeback
> facilities to users. You can put your charging rules into the plugin and
> have it spit out appropriate charg
On Mon, July 2, 2007 22:17, Gregory Stark wrote:
> The way you described it there were records being inserted and later
> deleted.
> Why wouldn't you need vacuums?
>
> Or are all the records eventually deleted and then the table truncated or
> dropped before the next batch of inserts?
In a nuthsh
Josh Berkus <[EMAIL PROTECTED]> writes:
>> I'm working on cleaning up postgresql.conf and pg_settings for the
>> ...
>> seq_scan_cost: this is independant of all of the other _costs.
So? All the other costs are independent of it, too. I don't understand
what problem you have with it.
>> (chan
On Jul 2, 2007, at 6:03 AM, Josh Berkus wrote:
(change requires restart): this phrase appears over 20 times in the
notes. This is enough times to be really repetitive and take up a
lot of scrolling space, while not actually covering all startup-
time parameters. We should either (a) remove
On Jul 1, 2007, at 4:46 PM, Tom Lane wrote:
I have question. Is correct implementation of global temp in
Oracle or
Firebird, where content of glob.temp table is session visible and
metadata of g.t.t is persistent?
It's correct per spec. Whether it's more useful than what we do is
highly deba
On Fri, 2007-06-29 at 14:43 -0400, Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > Yes, it's not intended to insert more stats, but to get the raw data out
> > for external analysis during development and testing of applications and
> > systems etc.
>
> Mph --- the proposal was very po
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Actually, come to think of it, I don't think I'd want any vacuums at all
> on this particular table. Just the analyze on the primary key, no
> vacuums, no statistics on anything else. Unfortunately it's not just one
> table, but a set of tables
On Mon, July 2, 2007 18:15, Gregory Stark wrote:
>> So I suppose the planner has a good reason to ignore the index at that
>> point. I'm assuming that this is something to do with the correlation
>> between the index and the column's statistics degrading in some way.
>
> Best to post "explain ana
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> So I suppose the planner has a good reason to ignore the index at that
> point. I'm assuming that this is something to do with the correlation
> between the index and the column's statistics degrading in some way.
Best to post "explain analyze
This time *with* the attachment.
All,
I'm working on cleaning up postgresql.conf and pg_settings for the
release. Attached is a sample WIP. It's not in patch form because I'm
not done yet; I've just been editing postgresql.conf and need to fix the
docs and pg_settings to match.
Issues
All,
I'm working on cleaning up postgresql.conf and pg_settings for the
release. Attached is a sample WIP. It's not in patch form because I'm
not done yet; I've just been editing postgresql.conf and need to fix the
docs and pg_settings to match.
Issues encountered and changes made:
Postgr
Hi all,
I've run into a case where I get bad performance that doesn't sound too
hard to solve. Question is: is it worth solving?
The situation is this: I have a table that can grow to a large number of
rows, then shrink to zero over a large number of quick, consecutive
transactions. The primary
On Sun, Jul 01, 2007 at 07:20:08PM -0700, Eric wrote:
>
> >
> > Everything is always passed as a Datum, so yes, it's is determined by
> > the storage clause in CREATE TYPE.
>
> Still not sure what to do in some scenarios. One example is the gist
> example code for btree (btree_gist). If you loo
> To be honest..No trigger necessary...
I have 1300 triggers and 345 functions (53500 lines of code), most of
them written 15 years ago for ALLBASE/SQL (the old Hewlett Packard
relational dbms) and converted to pl/pgsql last year.
I admit that some of them may look eccentric, but some of them a
Ühel kenal päeval, E, 2007-07-02 kell 04:27, kirjutas Naz Gassiep:
> I've been warned away from hash indexes before, however I had no idea
> that it's performance was that abysmal that BTREE beat it and I was
> definitely not aware that they were not included in WAL logs. I was told
> it wasn't as
>
> Everything is always passed as a Datum, so yes, it's is determined by
> the storage clause in CREATE TYPE.
Still not sure what to do in some scenarios. One example is the gist
example code for btree (btree_gist). If you look at the int4 example
consistent function, it gets an int32 value (p
43 matches
Mail list logo
