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
Ü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
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
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 look at the
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
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:
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
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 query
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 analyze
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 that
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 poorly
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
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
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.
(change
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 nuthshell,
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 chargeback
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_class.
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 ship the
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
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 charging rules
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
somehow
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 involve
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
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
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
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 not
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 was a
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 to 256KB,
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.
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
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
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
cloning a
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 anyway.
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. The most
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
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/dboid/pg_temp_backendid/relfilenode
So each
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
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
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 default
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 beyond use autovac?
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
How about a new relkind which causes the table to be located in
PGDATA/base/dboid/pg_temp_backendid/relfilenode
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,
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 creating
43 matches
Mail list logo
