--On Dienstag, März 16, 2004 17:34:25 -0800 Jonathan Gardner
[EMAIL PROTECTED] wrote:
Would you like to work with incrementally updating materialized views? I
am currently deleting then reinserting rows that get updated with a
pretty stupid algorithm. If you would like to investigate
I am currently thinking of updateable views for a possible student research
project. In this
case there comes some points to my mind, i want to share with the list.
a) Definition of an updateable view?
The first thing what i thought about was, what defines a updateable view.
An updateable
view
--On Montag, März 22, 2004 16:17:34 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[...]
We might need to mark automatically created rules as such, and be
prepared to drop them if the user then defines a manually-created rule.
Otherwise we will have backwards
--On Montag, März 22, 2004 18:00:55 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
That sounds bogus to me. It's obvious that columns not present in the
view can't be updated through the view --- you simply do not have a way
to name them, so how could you affect them?
What the spec actually says, if
--On Samstag, Mai 08, 2004 14:14:10 +0200 Gaetano Mendola
[EMAIL PROTECTED] wrote:
Hi all,
about you is it ok for you if I write the email built in type ?
I know of course that I can do it with a DOMAIN.
Regards
Gaetano Mendola
Funny, I had the idea some time ago, too. The problem was that I
By accidently passing a NULL pointer in a RuleStmt's RangeVar relname i
recognized
that this can lead to a crash of the backend in the function hashname(),
located in hashfunc.c. It calls strlen() without checking the key pointer
in line 126, which leads on my machine to a null pointer
I have this on 8.0dev (checked out last friday):
yomama=# SELECT version();
version
---
PostgreSQL 8.0devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.0
(1 Zeile)
yomama=# CREATE TABLE
While having trouble extending the CREATE VIEW grammar i discovered this:
[EMAIL PROTECTED]:yomama #= CREATE VIEW vtest as SELECT * from abteilung WITH;
CREATE VIEW
I can reproduce this on 8.0.0beta1 beta3 and in a 7.4.2 production
database.
Bernd
---(end of
--On Donnerstag, September 30, 2004 16:32:48 -0700 Stephan Szabo
[EMAIL PROTECTED] wrote:
On Fri, 1 Oct 2004, Bernd Helmle wrote:
While having trouble extending the CREATE VIEW grammar i discovered this:
[EMAIL PROTECTED]:yomama #= CREATE VIEW vtest as SELECT * from abteilung
WITH; CREATE VIEW
Got this after a fresh cvs update -d -P:
../../../../src/include/storage/s_lock.h: In function `tas':
../../../../src/include/storage/s_lock.h:124: warning: read-write
constraint does not allow a register
../../../../src/include/storage/s_lock.h:124: warning: read-write
constraint does not allow
--On Montag, Oktober 18, 2004 17:23:47 +0200 Bernd Helmle
[EMAIL PROTECTED] wrote:
Got this after a fresh cvs update -d -P:
../../../../src/include/storage/s_lock.h: In function `tas':
../../../../src/include/storage/s_lock.h:124: warning: read-write
constraint does not allow a register
[sorry if this mail appears more than once, but it seems the others didn't
make it through the list]
This is a short preview on the view update code i'm currently working on.
It is far away from being ready, but i want to share the current code and
get some hints, what things have to be made
--On Dienstag, Oktober 26, 2004 13:02:27 +0200 Bernd Helmle
[EMAIL PROTECTED] wrote:
[sorry if this mail appears more than once, but it seems the others
didn't make it through the list]
This is a short preview on the view update code i'm currently working on.
It is far away from being ready
--On Dienstag, Oktober 26, 2004 23:44:10 +0300 Hannu Krosing [EMAIL PROTECTED]
wrote:
Thus I think that reserved keyword is what it is meant to be in the
first place ;)
Yes, that was my intention, too. That's because i went straight forward and
put it in the reserved keyword list and didn't
As somebody already noticed i'm working on view update rules for (currently
SQL92 only) updateable views. There are some issues i would like to hear
the opinion of experienced pgsql-hackers about (and maybe get some pointers
to solve them):
Column DEFAULT values aren't automatically inherited
--On Sonntag, November 28, 2004 14:55:29 +0100 Thomas Hallgren
[EMAIL PROTECTED] wrote:
From what I can see, the current JDBC driver uses the lo_xxx client
api's and they seem to map to the inv_xxx server api's.
Huh, does that mean the libpq's lo_*() API is deprecated, too? That would
be bad
I'm still playing around with the ALTER OBJECT SET SCHEMA stuff. I managed
to alter indexes and constraints as well for tables, but with SERIAL
sequences there is one little problem:
When altering a sequence created by a SERIAL column type (i do this by
examining pg_depend to avoid moving any
--On Dienstag, Juni 28, 2005 09:38:56 +0800 Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Does ALTER TABLE/RENAME code help you? You can rename sequences with
that...
Hmm, that doesn't cover pg_attrdef.adbin. I think the best way is to create
the default expressions from scratch, as Tom
--On Dienstag, Juni 28, 2005 02:01:33 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Not adsrc --- that's not trustworthy.
Yes, that's documented in the docs, too.
In practice I think you could just assume you know what the default
expression ought to be, and store a new one without looking at
--On Dienstag, Juni 28, 2005 01:43:27 +0200 Bernd Helmle
[EMAIL PROTECTED] wrote:
When altering a sequence created by a SERIAL column type (i do this by
examining pg_depend to avoid moving any other sequences that are
'foreign'), i need to recreate the default expression for the SERIAL
column
I discovered the following confusing issue in CVS HEAD:
CREATE TABLE test(id SERIAL NOT NULL);
ALTER TABLE TEST OWNER TO testuser;
SELECT typname, typowner, relname, relowner from pg_type c JOIN pg_class d
ON (d.reltype = c.oid) WHERE typname = 'test';
typname | typowner | relname | relowner
Bruce Momjian wrote:
I am not sure it was reported to you but this has been corrected:
I saw Tom's fixes on -committers, thank you.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
--On Samstag, Oktober 15, 2005 17:20:06 +0200 Martijn van Oosterhout
kleptog@svana.org wrote:
Although the
effect is obvious for functions, it seems to me that it would be cool
to make a CREATE OR REPLACE TABLE that simply does nothing if the table
already exists with the right format.
Hmm i
--On Montag, Dezember 13, 2004 17:23:06 +0100 Peter Eisentraut
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Instead of doing that, do:
--with-includes=/usr/include/et
This same workaround is in the RPMs. I wonder if it would be
worthwhile for configure
--On Mittwoch, Dezember 22, 2004 11:25:42 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
Richard Huxton dev@archonet.com writes:
There are two things (AFAICT) you need to be able to do to update (NOTE
- not insert) a view.
1. Identify the underlying table(s) for the updated column(s)
2. Identify
For automatic view update rules we are planning to implement column default
value inheritance, so that the view's column definition inherits from their
base table columns (and nobody has to use an explicit ALTER TABLE view
ALTER col SET DEFAULT ... ). Note that we will do that only for views,
--On Freitag, Februar 25, 2005 12:02:47 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
I wouldn't mind seeing people be a little more vocal on the hackers list
about what they plan to be doing, just so that there's not duplication
of effort.
Jaime Casanova and me are still working on view update rules.
--On Samstag, März 19, 2005 11:05:39 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Why do you not define the problem as when we decide a view is
updateable and create the needed rules for it,
--On Montag, März 28, 2005 09:51:52 +0100 Simon Riggs
[EMAIL PROTECTED] wrote:
[...]
If you have everything else working, it might be worth submitting a
patch for review? There may be other things required also.
Best Regards, Simon Riggs
Well, the patch is far away from being ready for -patches,
--On Mittwoch, März 30, 2005 11:35:05 -0400 Alvaro Herrera
[EMAIL PROTECTED] wrote:
On Tue, Mar 29, 2005 at 07:30:13PM +0200, Bernd Helmle wrote:
Well, the patch is far away from being ready for -patches, but if you
want to preview you can get our latest patch against HEAD at
http
--On Dienstag, April 05, 2005 16:19:54 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
I've gotten a bee in my bonnet again about Resdom being wasteful.
There is no case where Resdom appears without TargetEntry, nor vice
versa, so we ought to fold them into a single node type. Is anyone
out there
--On Donnerstag, April 07, 2005 20:48:12 -0400 Alvaro Herrera
[EMAIL PROTECTED] wrote:
One piece of wisdom I've managed to grasp is that when Tom asks for
objections or comments, you better speak very quickly because he codes
way too fast (that, or he posts when the patch is almost ready.)
Hehe,
I've took a look at the TODO item
Allow objects to be moved to different schemas
I've done some code so far which implements the syntax
ALTER [OBJECT] name SET SCHEMA name
where OBJECT currently is
SEQUENCE
TABLE
--On Donnerstag, Juni 09, 2005 10:33:08 +0800 Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
them as well or leave them in the source namespace?
--On Mittwoch, Juni 08, 2005 14:49:56 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
The code seems fairly schizoid about whether the operation is an alter
namespace or a rename. Please be consistent. I'd say it is *not*
a rename, but I suppose you could make an argument the other way ...
No, i
--On Mittwoch, Juni 08, 2005 14:48:55 -0400 Alvaro Herrera
[EMAIL PROTECTED] wrote:
On Wed, Jun 08, 2005 at 08:25:12PM +0200, Bernd Helmle wrote:
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
--On Donnerstag, Juni 09, 2005 21:05:59 +0800 Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Oh yes, you're probably right. Indexes should move though I think?
Yes, i think so, too.
--
Bernd
---(end of broadcast)---
TIP 5: Have you
--On Donnerstag, Juni 09, 2005 12:05:45 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
I don't think you have any choice about that --- I'm pretty sure that
there are places that assume a table's indexes are in the same schema
the table is. Constraints ditto.
Okay, then the consenus is to go for
--On Donnerstag, Juni 09, 2005 10:17:33 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Hmm? You're planning to write into the relation in question. It's
hardly likely that the structure can be expected to remain virgin...
in practice I don't think we guarantee that even for read operations.
Oh,
--On Freitag, Juni 10, 2005 21:20:33 +0200 [EMAIL PROTECTED] wrote:
Wouldn't
ALTER [OBJECT] RENAME TO [schema.][name]
be a better?
After all, this is essentially a rename operation,
so maybe it is better to extend existing syntax...
I don't think it's a good idea to merge two different
[sorry to everyone if that mail arrives multiple times, but i had
some odd problems with my mail gateway yesterday...]
On Wed, Mar 01, 2006 at 12:41:01PM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
How does an optimistic FSM entry avoid the need to run
On Wed, Mar 01, 2006 at 12:41:01PM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
How does an optimistic FSM entry avoid the need to run vacuum?
It ensures that all freed tuples are already in the FSM.
That has nothing to do with it, because the space
Hi folks,
Please find attached a patch that implements SQL92-compatible updatable
views. The patch introduces new semantics into the rule system: implicit
and explicit rules. Implicit rules are created to implement updatable views:
_INSERT
_NOTHING_INSERT (unconditional DO INSTEAD NOTHING
--On Donnerstag, März 09, 2006 17:23:11 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
(BTW, there was some work being done on updatable views, but I think
it's stalled. I suspect the reason is that our current rule system
is just too odd to support updatable views reasonably. I've been
--On Freitag, März 10, 2006 09:43:04 + Richard Huxton
dev@archonet.com wrote:
I'd certainly be interested in having auto-updatable views in 8.2 - even
if it was only for the simplest of cases. If I can be of any help testing
etc. let me know.
Yeah, that would be cool. I've sent the
--On Sonntag, März 12, 2006 23:52:12 -0500 Neil Conway [EMAIL PROTECTED]
wrote:
On Fri, 2006-03-10 at 11:21 +0100, Bernd Helmle wrote:
Please find attached a patch that implements SQL92-compatible updatable
views.
I'm currently reviewing this. Comments later...
ok
Please note
--On Mittwoch, Mai 10, 2006 10:14:22 +0200 Mario Weilguni
[EMAIL PROTECTED] wrote:
No, I want that there is a setting or GUC that controls whether an error
or a warning is raised when begin is executed within a transaction. I
know of several php database wrappers that will be seriously
--On Mittwoch, Mai 10, 2006 12:36:07 +0200 Mario Weilguni
[EMAIL PROTECTED] wrote:
Such a behavior is already broken by design. I think it's not desirable
to blindly do
transaction start or commit without tracking the current transaction
state. So these wrappers
need to be fixed first.
--On Mittwoch, Juli 12, 2006 20:58:08 -0500 Jaime Casanova
[EMAIL PROTECTED] wrote:
if nobody step up i can do the list.
i think this is the last patch that he post:
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php
The code drifted since then in some parts. I'll sent a
--On Mittwoch, Juli 12, 2006 09:30:38 -0700 Joe Conway [EMAIL PROTECTED]
wrote:
Jaime Casanova wrote:
is anybody working on the Bernd Helmle's updateable views patch? or
know what the status of this is?
I'm still working on this and trying to get all open issues done for 8.2
feature
--On Freitag, Juli 14, 2006 01:23:11 +0200 Peter Eisentraut
[EMAIL PROTECTED] wrote:
. multiple values clauses for INSERT
Susanne Ebrecht [EMAIL PROTECTED] was last heard to work on
it. Updates, Susanne?
I've talked to Susanne today and she's just back from hospital and not
available
--On Dienstag, August 22, 2006 23:12:21 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
At the moment, with the online-index and updatable-views patches both
pretty seriously broken, and no sign that the bitmap-index people are
awake at all, I might take it on myself to fix this one instead of
--On Mittwoch, August 23, 2006 08:24:55 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
What are these open issues for the updatable views patch you are seeing
exactly?
Didn't Alvaro list a bunch of issues when he put the patch back up for
comment? I have not looked at it myself yet.
Indeed he
--On Donnerstag, August 24, 2006 11:00:45 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
If the code is dependent on recognizing names to know what it's doing,
then I'd say you have a fundamentally broken approach. Consider adding
a flag column to pg_rewrite to distinguish these rules, instead.
--On Donnerstag, August 24, 2006 11:02:43 -0500 Jaime Casanova
[EMAIL PROTECTED] wrote:
Actually the code delete implicit rules based on a field added to
pg_rewrite but that catalog has a unique index on ev_class, rulename:
pg_rewrite_rel_rulename_index UNIQUE, btree (ev_class, rulename)
i
--On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
--On Donnerstag, August 31, 2006 11:10:47 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
The problem is not with the view condition. Consider
CREATE TABLE data (id serial primary key, ...);
CREATE VIEW only_new_data AS SELECT * FROM data WHERE id 12345
WITH CHECK
PROTECTED] wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
You're certainly welcome to work on it --- I don't have time at the
moment. But I agree there's little chance of getting it done in time
for 8.2.
What we can do is to restrict view updates that involves a volatile function
--On Freitag, September 01, 2006 11:34:49 -0400 Alvaro Herrera
[EMAIL PROTECTED] wrote:
I don't understand this part very well. Say if you have a view WITH
CHECK OPTION whose condition is foo 5, and then define a view WITH
LOCAL CHECK OPTION on top of that, whose condition is bar 5. Does
--On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
So in other words, views on serial columns don't work? I don't think
that's going to be acceptable.
They work in such a case that someone isn't allowed to put a volatile
function in an update query
--On Montag, September 04, 2006 23:58:35 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Updatable views are likewise dead --- we don't have a credible patch or
any short-term path to get one. I hope to see both of these items land
early in the 8.3 devel cycle, but for 8.2, nyet.
Yeah, i don't had
Please find attached my current patch for automatic view update rules.
This is a stripped down version of my former patch discussed before 8.3
without CHECK OPTION support and less invasive changes to the rewriter
itself.
I'm currently cleaning up the code with all occurences of multiple
--On Donnerstag, Oktober 30, 2008 21:24:08 +0100 Bernd Helmle
[EMAIL PROTECTED] wrote:
Note that i'm still working on this (for example, RETURNING is missing
yet), As always, discussion welcome ;)
This new version implements RETURNING support for implicit view update
rules and does some
--On Samstag, Oktober 25, 2008 23:50:47 +0200 Guillaume Lelarge
[EMAIL PROTECTED] wrote:
Hi,
Here is my patch to add the ALTER DATABASE WITH TABLESPACE statement. It
is part of the TODO list. It intends to allow the move of all relations
of a database in its new default tablespace.
Comments
--On Dienstag, November 04, 2008 14:56:44 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
[...]
Not sure what Bernd tried exactly, but it can be done.
Cool, i didn't recognize the obvious possibility to add a separate rule for
this. I've just extended the alterdb_opt_item with SET TABLESPACE,
--On Dienstag, November 04, 2008 17:12:15 -0800 Unicron
[EMAIL PROTECTED] wrote:
I am reviewer of Patch Table command. I wanted to build code checked
out from code repo
got via rsyn, but I didn't find relating code in file gram.y. Do i need
to add the code to the file?
The patch doesn't
--On Mittwoch, November 05, 2008 01:10:22 +0100 Guillaume Lelarge
[EMAIL PROTECTED] wrote:
Tom Lane a écrit :
Guillaume Lelarge [EMAIL PROTECTED] writes:
Should I provide a complete new patch with Bernd's and Tom's changes?
Please --- it's better if you integrate it since you know the
--On Mittwoch, November 05, 2008 19:20:07 -0500 Tom Lane
[EMAIL PROTECTED] wrote:
No, I think that should just be a no-op. We don't for instance throw
error when you ALTER OWNER to the existing owner.
Hmm okay. When looking at this i was remembering the discussion we had for
SET SCHEMA a
--On Donnerstag, November 06, 2008 11:35:54 +0100 Guillaume Lelarge
[EMAIL PROTECTED] wrote:
Guillaume Lelarge a écrit :
v4 patch attached.
v5 patch attached.
Thanks Guillaume.
Maybe this is nit-picking, but i see that you have to rmdir() an existing
empty tablespace directory to use
--On Freitag, November 07, 2008 09:36:32 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd, did you have any further comments? If not I'll get started on
this patch.
No, i think this patch is ready for a committer then.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing
--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel!
[EMAIL PROTECTED] wrote:
On Nov 7, 2008, at 9:53 AM, Tom Lane wrote:
FWIW, I don't see this patch as being terribly useful in the real world
until it can take place in the background, without locking stuff for a
huge amount of time.
--On Dienstag, November 11, 2008 23:06:08 -0500 Robert Haas
[EMAIL PROTECTED] wrote:
Thanks for your look at this. Unfortunately i was travelling the last 2
days, so i didn't have time to reply earlier, sorry for that.
I haven't done a full review of this patch, but here are some thoughts
--On Dienstag, November 25, 2008 23:43:02 -0500 Robert Haas
[EMAIL PROTECTED] wrote:
Do you intend to submit an updated version of this patch for this
commitfest?
I'll do asap, i've updated the status to 'waiting on author'.
--
Thanks
Bernd
--
Sent via pgsql-hackers
--On Donnerstag, August 07, 2008 08:03:52 -0400 Robert Haas
[EMAIL PROTECTED] wrote:
Here's a patch that allows CREATE OR REPLACE VIEW to add new columns
to an existing view.
Any feedback would be appreciated, especially if it meant that I could
fix any problems before the next commitfest.
--On 14. November 2009 20:22:42 -0500 Robert Haas robertmh...@gmail.com
wrote:
I will take another crack at it.
...Robert
I take this that you are going to provide a new patch version?
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
--On 16. November 2009 11:00:33 -0700 Alex Hunsaker bada...@gmail.com
wrote:
Anyway Bernd if you are working on this great! If not lemme know, Ill
plan on having something for the next commit feast. Though I still
may never get around to it :(.
I'm just working on it.
The current patch
--On 13. November 2009 23:29:41 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
t contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I merged it with the head.
Original end of mail thread is here:
--On 14. November 2009 15:25:25 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
Hmm, const is also problem on solaris. dtrace generates probe.h file and
eats const. It generates following noise on solaris build:
postgres.c, line 554: warning: argument #1 is incompatible with
prototype:
--On 13. November 2009 17:16:15 -0500 Robert Haas robertmh...@gmail.com
wrote:
Don't think. Benchmark. :-)
(If you can measure it at all, it's too much, at least IMHO.)
I've tried to benchmark this now on my (fairly slow compared to server
hardware) MacBook and see some negative trend
--On 8. Dezember 2009 15:51:52 -0500 Greg Smith g...@2ndquadrant.com
wrote:
Try this instead, which will give you a test where checkpoints have a
minimal impact, but lots of memory will be thrown around:
pgbench -i -s 10 db
pgbench -S -c 10 -T 600 db
Thanks for the input, will try
--On 8. Dezember 2009 11:10:44 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
If you think that it is better I could split patch into two separate
patches and both can be reviewed separately.
I split up this patch into two separate patches: one for SLRU and one for
the executor probes.
--On 9. Dezember 2009 19:08:07 -0500 Theo Schlossnagle je...@omniti.com
wrote:
Now, there was some indication that there was a better place to probe
that would be more comprehensive -- that should be addressed.
For now there exists no consensus where they should go in. Tom pointed out
--On 10. Dezember 2009 09:59:44 -0800 Josh Berkus j...@agliodbs.com wrote:
(The Mac Openjade toolchain is unalterably broken, AFAICT) Without
editing the makefiles, it wasn't possible to build PostgreSQL on my OSX
10.4 laptop.
You might get an idea how i fixed that here:
--On 10. Dezember 2009 23:55:49 -0500 Robert Haas robertmh...@gmail.com
wrote:
If there's some real-world test where this probe costs 0.3%-0.4%, I
think that is sufficient grounds for rejecting this patch. I
understand the desire of people to be able to use dtrace, but our
performance is
--On 11. Dezember 2009 11:28:54 -0300 Alvaro Herrera
alvhe...@commandprompt.com wrote:
without compiled probes: AVG(2531.68)
with compiled probes: AVG(2511.97)
Were the probes enabled?
Hmm, they were just compiled in, i didn't anything to instrument them with
dtrace.
I've just
--On 10. Dezember 2009 16:49:50 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
You need to determine which SLRU is used. Because SLRUs are initialized
during startup pointer should be same in all backends. If I think more
about it. Maybe it could be goot to add probe also into
--On 14. Dezember 2009 07:49:34 -0500 Robert Haas robertmh...@gmail.com
wrote:
Since the author has pretty much admitted he didn't fix any of the
issues that were raised by the last committer review, I'm a little
confused about why you're asking for another one.
It wasn't clear to me what
--On 14. Dezember 2009 20:33:12 +0100 Bernd Helmle maili...@oopsware.de
wrote:
Since the author has pretty much admitted he didn't fix any of the
issues that were raised by the last committer review, I'm a little
confused about why you're asking for another one.
It wasn't clear to me what
--On 15. Dezember 2009 12:10:09 -0500 Greg Smith g...@2ndquadrant.com
wrote:
But I'm afraid we're already out of time for this one if you're still
tweaking the probes here. With a functional change like that, our
normal process at this point would be to have the reviewer re-evaluate
things
--On 21. Dezember 2009 10:01:37 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
It's not supposed to. Use pg_total_relation_size if you want a number
that includes index and toast space.
I've created a C-Function a while ago that extracts the TOAST size for a
given relation. This gave me the
--On 22. Dezember 2009 11:46:32 +0100 Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Did you mean :
pg_table_size() = base table + toast table
pg_indexes_size() = base indexes + toast indexes
?
Since you always have a toast index automatically it makes sense to include
them
--On 21. Dezember 2009 12:02:02 -0500 Greg Smith g...@2ndquadrant.com
wrote:
Tom Lane wrote:
Perhaps invent pg_table_size() = base table + toast table + toast index
and pg_indexes_size() = all other indexes for table
giving us the property pg_table_size + pg_indexes_size =
--On 22. Dezember 2009 15:11:40 +0100 Bernd Helmle maili...@oopsware.de
wrote:
Bernd, there's a basic spec if you have time to work on this.
I see if i can get some time for it during christmas vacation (its on my
radar for a longer period of time). I'm still working on this NOT NULL
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut pete...@gmx.net
wrote:
Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
For someone like me it's hard to
--On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei kai...@ak.jp.nec.com
wrote:
This patch adds:
List *find_column_origin(Oid relOid, const char *colName)
It returns the list of relation OIDs which originally defines the given
column. In most cases, it returns a list with an element. But,
--On 23. Januar 2010 22:29:23 -0500 Robert Haas robertmh...@gmail.com
wrote:
I don't think this is ready for committer, becauseTom previously
objected to the approach taken by this patch here, and no one has
answered his objections:
--On 24. Januar 2010 08:37:13 -0500 Robert Haas robertmh...@gmail.com
wrote:
I agree - the requirements here are much looser than for, say, SELECT
or UPDATE. But it still has to not suck.
Yeah, i think the meaning of suck can be much weakier than for a DML
command. However, if it would
--On 24. Januar 2010 13:23:14 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
I think my concern about the original proposal was that the time to
perform an ALTER RENAME would increase with the number of tables in the
database, even if they were entirely unrelated to the one you're trying
to rename.
--On 24. Januar 2010 19:45:33 +0100 Bernd Helmle maili...@oopsware.de
wrote:
I don't see where this should be related to the number of tables not
part of the inheritance tree (or inheritance at all).
To answer that myself: it seems get_attname() introduces the overhead here
(forgot
--On 25. Januar 2010 09:30:56 -0500 Robert Haas robertmh...@gmail.com
wrote:
This will turn into
another setting like search_path and standard_conforming_strings that
can break working code if the actual value doesn't match the
anticipated value. I can't figure out why someone would want
1 - 100 of 405 matches
Mail list logo
