I was wondering if the index-only-scan will be available in 9.2? This is not
having to visit the real data to answer a query, if all the information is
available in the index. I think this will be a mayor step in overtaking the big
O in the g-spot.
There seams to already be some patch for this
On Wed, 2011-10-12 at 02:08 +0200, hans wulf wrote:
I was wondering if the index-only-scan will be available in 9.2? This
is not having to visit the real data to answer a query, if all the
information is available in the index. I think this will be a mayor
step in overtaking the big O in the
2011/10/14 Bruce Momjian br...@momjian.us:
Should this be marked as TODO?
I suppose TODO items *are* wanted and so working on them should remove
the pain to convince people here to accept the feature, aren't they ?
---
Hi,
We have several users working on a 8.4 database, using it as a
back-end for several related apps and transfering data to and from it.
The database tends to get a bit messy, so i've made a little table to
provide an overview.
This table is truncated and refilled daily, it shows all tables and
On 14.10.2011 11:44, Cédric Villemain wrote:
2011/10/14 Bruce Momjianbr...@momjian.us:
Should this be marked as TODO?
I suppose TODO items *are* wanted and so working on them should remove
the pain to convince people here to accept the feature, aren't they ?
I don't think this is
On Thu, Oct 13, 2011 at 10:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 12, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2dev and 9.1, when walreceiver detects an error while sending data
2011/10/13 Jun Ishiduka ishizuka@po.ntts.co.jp:
I updated to patch corresponded above-comments.
Thanks for updating the patch!
As I suggested in the reply to Simon, I think that the change of FPW
should be WAL-logged separately from that of HS parameters. ISTM
packing them in one WAL record
On Thu, Oct 13, 2011 at 9:35 PM, Bruce Momjian br...@momjian.us wrote:
I assume this was addressed with this commit:
commit 465883b0a2b4236ba6b31b648a9eabef3b7cdddb
Author: Simon Riggs si...@2ndquadrant.com
Date: Tue Jun 28 22:58:17 2011 +0100
Introduce
On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mié may 25 16:07:55 -0400 2011:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
Right.
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
2011/10/14 Bruce Momjian br...@momjian.us:
Should this be marked as TODO?
I suppose TODO items *are* wanted and so working on them should remove
the pain to convince people here to accept the feature, aren't they ?
Hello,
I am writing an extension to easily execute queries with conditions
expressing constraints in fuzzy logics.
I wrote some C functions that get or set global variables in C.
The variables are MU (FLOAT : degree of a fuzzy predicate), ALPHA
(FLOAT : threshold for filtering predicates) and K
Tom Lane wrote:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2011/10/14 Bruce Momjian br...@momjian.us:
Should this be marked as TODO?
I suppose TODO items *are* wanted and so working on them should remove
the pain to convince people here to accept the
Robert Haas wrote:
On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mi? may 25 16:07:55 -0400 2011:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mar may 24 17:11:17
Excerpts from Robert Haas's message of vie oct 14 09:36:47 -0300 2011:
On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Oh, true, we have that, though it's not very usable because you have to
rename the file from .psqlrc-9.0.3 to
Excerpts from Bruce Momjian's message of vie oct 14 11:56:22 -0300 2011:
Tom Lane wrote:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2011/10/14 Bruce Momjian br...@momjian.us:
Should this be marked as TODO?
I suppose TODO items *are* wanted and
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie oct 14 11:56:22 -0300 2011:
Tom Lane wrote:
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com
writes:
2011/10/14 Bruce Momjian br...@momjian.us:
Should this be marked as TODO?
I
On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On the third hand, Josh's previous batch of changes to clean up
psql's behavior in this area are clearly a huge improvement: you can
now display the comment for nearly anything by running the appropriate
\dfoo command
On Fri, Oct 14, 2011 at 11:12 AM, Bruce Momjian br...@momjian.us wrote:
OK. But if we are pretty sure we don't want something, e.g. hibernate,
we shouldn't add it.
Fair enough, but I'm not even slightly sure that we don't want that.
I think having prewarming utilities available as contrib
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of vie oct 14 11:56:22 -0300 2011:
Tom Lane wrote:
There is plenty of stuff in the TODO list for which there is no
consensus.
Uh, we should probably remove those then. Can you think of any?
Unless
Excerpts from Bruce Momjian's message of vie oct 14 12:12:22 -0300 2011:
Alvaro Herrera wrote:
The guideline, last I checked, was that before getting into coding any
item from the TODO list, the prospective hacker should check previous
discussions and initiate a new one on this list to
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 14, 2011 at 11:12 AM, Bruce Momjian br...@momjian.us wrote:
OK. But if we are pretty sure we don't want something, e.g. hibernate,
we shouldn't add it.
Fair enough, but I'm not even slightly sure that we don't want that.
I think having
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie oct 14 12:12:22 -0300 2011:
Alvaro Herrera wrote:
The guideline, last I checked, was that before getting into coding any
item from the TODO list, the prospective hacker should check previous
discussions and
On Thu, Oct 13, 2011 at 12:27 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch fixes this problem.
Unfortunately, we have no code that invokes get_object_address()
with missing_ok = true now, so please apply a couple of patches
to rework DROP statement of mine.
DROP TRIGGER
Excerpts from Tom Lane's message of mar sep 20 21:30:42 -0300 2011:
The buildfarm is still showing isolation test failures more days than
not, eg
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pikadt=2011-09-17%2012%3A43%3A11
and I've personally seen such failures when testing with
Consider this example in an empty database:
db=# create table t1 (f1 int);
CREATE TABLE
db=# create unique index t1f1 on t1(f1);
CREATE INDEX
db=# create table t2 (f2 int references t1(f1));
CREATE TABLE
db=# create table t3(f3 int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mar sep 20 21:30:42 -0300 2011:
Could we please fix those tests to not have such
fragile timing assumptions?
The fix has now been installed for two weeks and no new failure has
occured. The only failure in
Robert Haas wrote:
On Wed, Jun 8, 2011 at 10:55 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 08-06-2011 20:35, Robert Haas escreveu:
Is the hint correct? ?I mean, what if there were 100 small tables that
needed vacuuming all at the same time. ?We'd hit this limit no matter
Is this going to be done for 9.2?
---
Greg Smith wrote:
Following up on the idea we've been exploring for making some extensions
more prominent, attached is the first rev that I think may be worth
considering
All,
I'm noticing some inconsistent and (I believe) undesirable behavior on
RAISE INFO.
If you call a function, and it posts progress reports using RAISE INFO,
then you get the INFO statements plain back to the client. However, if
that function calls another function, then you also get a
Is this a TODO?
---
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 09.06.2011 15:50, Robert Haas wrote:
And I would guess that there's a lot more interest in raising BLCKSZ
than
Ideally we would have something like checkpoint_warning that warns users
in the log when there are too few autovacuum workers and cleanup is
being delayed.
I don't think that any table-stats based approach is going to work. I
think you need to measure the queue of tables which need
On 14 October 2011 17:48, Bruce Momjian br...@momjian.us wrote:
Is this going to be done for 9.2?
---
I didn't spot this thread before. I posted something related
yesterday:
Is this important enough to back-patch? We can't force initdb in back
branches, but we could suggest that people could drop and re-create the
information_schema (I think that's supposed to work).
I wouldn't worry about emphasizing the rebuild. Most users don't use
information_schema, and
Excerpts from Josh Berkus's message of vie oct 14 13:52:32 -0300 2011:
All,
I'm noticing some inconsistent and (I believe) undesirable behavior on
RAISE INFO.
If you call a function, and it posts progress reports using RAISE INFO,
then you get the INFO statements plain back to the
Maybe set the verbosity to a lower level in the function? I dunno if
plpgsql lets you do that though. We have a GUC that controls the server
log verbosity, and psql can do it too; but plpgsql is sort of in
between.
The problem is that there is no level of verbosity which will supress
the
Excerpts from Josh Berkus's message of vie oct 14 14:16:43 -0300 2011:
Maybe set the verbosity to a lower level in the function? I dunno if
plpgsql lets you do that though. We have a GUC that controls the server
log verbosity, and psql can do it too; but plpgsql is sort of in
between.
Bruce Momjian br...@momjian.us wrote:
Is this a TODO?
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
If we don't want to change it wholesale, one option would be to
support different lengths of filenames in slru.c for different
slrus. At a quick glance,
I meant verbosity, not error level. This quick test shows what I meant
-- but it doesn't work; the server log is altered as I expected (and does not
include the context lines), but not plpgsql's:
Yeah, what we'd need is a client_error_verbosity setting.
--
Josh Berkus
PostgreSQL Experts
On Fri, Oct 14, 2011 at 12:59 PM, Josh Berkus j...@agliodbs.com wrote:
Ideally we would have something like checkpoint_warning that warns users
in the log when there are too few autovacuum workers and cleanup is
being delayed.
I don't think that any table-stats based approach is going to
On Fri, Oct 14, 2011 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is this important enough to back-patch?
IMHO, yes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Oct14, 2011, at 19:27 , Josh Berkus wrote:
I meant verbosity, not error level. This quick test shows what I meant
-- but it doesn't work; the server log is altered as I expected (and does not
include the context lines), but not plpgsql's:
Yeah, what we'd need is a client_error_verbosity
Excerpts from Florian Pflug's message of vie oct 14 14:41:11 -0300 2011:
On Oct14, 2011, at 19:27 , Josh Berkus wrote:
I meant verbosity, not error level. This quick test shows what I meant
-- but it doesn't work; the server log is altered as I expected (and does
not
include the
We do transmit the individual parts of a NOTICE separately, so I'd say
suppressing some of them is the client's job. So, instead of a GUC I'd say
we'd need a psql setting ERROR_VERBOSITY.
Well, we do have a psql setting as well (\set VERBOSITY). But is Josh
using psql?
Not in this
On Wed, Oct 12, 2011 at 7:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Phil Sorber p...@omniti.com writes:
Then there is a separate section of code that is called as a separate
function 'dumpUserConfig()' that does other role attributes like
'ALTER ROLE bob SET role TO charlie'. These are the
This evening, David Fetter described a problem to me that he was
having building the Twitter FDW. It transpired that it was down to its
dependence on an #include that was recently judged to be
redundant.This seems like another reason to avoid using pgrminclude -
even if we can be certain that the
Excerpts from Peter Geoghegan's message of vie oct 14 15:36:32 -0300 2011:
This evening, David Fetter described a problem to me that he was
having building the Twitter FDW. It transpired that it was down to its
dependence on an #include that was recently judged to be
redundant.This seems like
Magnus Hagander wrote:
On Wed, Jun 22, 2011 at 17:48, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Something along the line of this?
I think this is a seriously, seriously bad idea:
+#define strdup(x) pg_strdup(x)
+#define malloc(x) pg_malloc(x)
Where are we on this?
---
David Fetter wrote:
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-05-17 at 14:11 -0500,
Alexander Korotkov wrote:
Version of patch with few more comments and some fixes.
Where are we on this?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent
Alvaro Herrera wrote:
Excerpts from Robert Haas's message of vie oct 14 09:36:47 -0300 2011:
On Thu, Oct 13, 2011 at 11:31 AM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Oh, true, we have that, though it's not very usable because you have to
rename the file from
Bruce Momjian br...@momjian.us writes:
Oops, I see a problem. Right now, our first major release has no zero,
e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is
that with this patch it is confusing to have a psql config file that
matches 9.2.0, but not 9.2.5, because you
So I'm testing a patch to make the planner use measured all-visible-page
counts for index-only scans. I was expecting to possibly see some plan
changes in the regression tests, but this diff scared me:
***
*** 906,921
FROM tenk1 WHERE unique1 10;
sum | unique1
Josh Berkus j...@agliodbs.com writes:
I meant verbosity, not error level. This quick test shows what I meant
-- but it doesn't work; the server log is altered as I expected (and does not
include the context lines), but not plpgsql's:
Yeah, what we'd need is a client_error_verbosity setting.
Josh Berkus j...@agliodbs.com writes:
In any case, this doesn't address the inconsistency of supressing
CONTEXT for the first level of the call stack with RAISE INFO but not
for the others. (RAISE EXCEPTION shows CONTEXT for all levels of the
call stack).
Oh? I don't see that. AFAICT the
On Fri, Oct 14, 2011 at 3:24 PM, Bruce Momjian br...@momjian.us wrote:
Alexander Korotkov wrote:
Version of patch with few more comments and some fixes.
The CommitFest app page is here.
https://commitfest.postgresql.org/action/patch_view?id=539
It was reviewed in July by Nate Boley, and never
Now that we have syntax for adding miscellaneous options to RAISE
statements, what I suggest we consider is a RAISE option that suppresses
all context lines for the message, perhaps
RAISE NOTICE 'fee, fi, fo, fum' USING context = false;
Yeah, that would do it. Pavel? ;-)
--
Josh Berkus
On Fri, Oct 14, 2011 at 3:19 PM, Bruce Momjian br...@momjian.us wrote:
Where are we on this?
Well, I don't know. We had a couple of different ideas on what to do
about it, and I'm not sure anyone was completely in love with any of
the available options.
--
Robert Haas
EnterpriseDB:
On Oct14, 2011, at 20:00 , Josh Berkus wrote:
We do transmit the individual parts of a NOTICE separately, so I'd say
suppressing some of them is the client's job. So, instead of a GUC I'd say
we'd need a psql setting ERROR_VERBOSITY.
Well, we do have a psql setting as well (\set VERBOSITY).
On Oct14, 2011, at 23:51 , Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I meant verbosity, not error level. This quick test shows what I meant
-- but it doesn't work; the server log is altered as I expected (and does
not
include the context lines), but not plpgsql's:
Yeah, what
Florian Pflug f...@phlo.org writes:
On Oct14, 2011, at 23:51 , Tom Lane wrote:
It seems to me that a client-side facility would be unlikely to do the
right things, because it has not got enough information to know which
messages came from plpgsql RAISE commands. Moreover, it's not apparent
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Oops, I see a problem. Right now, our first major release has no zero,
e.g. 9.2, while our minors have a third digit, 9.2.5. The problem is
that with this patch it is confusing to have a psql config file that
matches 9.2.0, but not
As I suggested in the reply to Simon, I think that the change of FPW
should be WAL-logged separately from that of HS parameters. ISTM
packing them in one WAL record makes XLogReportParameters()
quite confusing. Thought?
I want to confirm the reply of Simon. I think we cannot decide how this
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
* Have you tested this on an architecture with strict alignment? I don't
see any alignment bugs, but I think there's a lot of potential for them..
Well, fwiw, this patch passes its regression tests on HPPA, except for this
which
if (!shutdown XLogStandbyInfoActive())
+ {
LogStandbySnapshot(checkPoint.oldestActiveXid,
checkPoint.nextXid);
+ XLogReportParameters(REPORT_ON_BACKEND);
+ }
Why doesn't the change of FPW need to be WAL-logged when
shutdown checkpoint is
2011/10/15 Tom Lane t...@sss.pgh.pa.us:
I can't recall whether there was some good reason for underspecifying
these test queries. It looks like all the problematic ones were added in
commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 Extend the set of frame
options supported for window
Hello
2011/10/15 Josh Berkus j...@agliodbs.com:
Now that we have syntax for adding miscellaneous options to RAISE
statements, what I suggest we consider is a RAISE option that suppresses
all context lines for the message, perhaps
RAISE NOTICE 'fee, fi, fo, fum' USING context = false;
Yeb Havinga yebhavi...@gmail.com writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
The biggest problem is that the patch cuts up and reassembles the
67 matches
Mail list logo
