Jeff Janes wrote:
Kevin Grittner wrote:
create table t (id int not null primary key);
insert into t select generate_series(1, 100);
vacuum freeze analyze;
explain analyze select count(*) from t
where id between 50 and 500010;
That gives you an index-only scan; but without the
On Tue, Oct 11, 2011 at 03:29, Florian Pflug f...@phlo.org wrote:
On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote:
It'd be nice to generally terminate a backend if the client vanishes, but so
far I haven't had any bright ideas.
On 11 October 2011 02:14, Florian Pflug f...@phlo.org wrote:
On Oct10, 2011, at 20:06 , Thom Brown wrote:
Okay, a real example of why discrete should be '[]' and continuous
should be '[)'.
If you book a meeting from 09:00 to 11:00 (tsrange), at 11:00
precisely it either becomes free or is
At Fri, 7 Oct 2011 12:25:08 -0400, Robert Haas robertmh...@gmail.com wrote in
ca+tgmoao2oozbmusfp3zc0_lgxsv3jbvy9eyr5h+czyez7j...@mail.gmail.com
OK, I think this is reasonably close to being committable now. There
are a few remaining style and grammar mistakes but I can fix those up
before
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts between rows and arrays. Now we have a
lot of tools for arrays, and these tools should be used for rows too.
postgres=# \d mypoint
Composite type public.mypoint
Column │ Type │ Modifiers
I can't see a reason why we would use a new WAL record for this,
rather than modify the XLOG_PARAMETER_CHANGE record type which was
created for a very similar reason.
The code would be much simpler if we just extend
XLOG_PARAMETER_CHANGE, so please can we do that?
Sure.
The log message
On Tue, Oct 11, 2011 at 12:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I have mostly-working code for approach #3, but I haven't tried to make
EXPLAIN work yet. While looking at that I realized that there's a
pretty good argument for adding the above-mentioned explicit TargetEntry
On Mon, Oct 10, 2011 at 3:15 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Right now, our costing model for index-only scans is pretty dumb.
It assumes that using an index-only scan will avoid 10% of the
heap fetches. That could easily be low,
On Mon, Oct 10, 2011 at 3:16 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/10/10 Robert Haas robertmh...@gmail.com:
On Mon, Oct 10, 2011 at 1:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
That gives you an index-only scan; but without the WHERE clause it
uses
Hi all,
I wonder, could the recent work on index only scans pave the way for auto
clustered tables? Consider a wide, mostly insert table with some subset of
columns that I'd like to cluster on. I'm after locality of tuples that are
very frequently fetched together, but not keen on the
The reported git failures from the buildfarm should clear on the next run -
they're the result of an upgrade to the git package on the git server which
left the git-daemon in an non-functioning state. It's back up now.
Apologies for the noise.
--
Dave Page
Blog: http://pgsnake.blogspot.com
On 08/10/2011, at 1:56 AM, Yeb Havinga wrote:
Attach is v2 of the patch.
Mixed notation now raises an error.
In contrast with what I said above, named parameter related errors are thrown
before any syntax errors. I tested with raising syntax errors first but the
resulting code was a
On Tue, Oct 11, 2011 at 2:36 PM, Robert Haas robertmh...@gmail.com wrote:
Have you given any thought to what would be required to support
index-only scans on non-btree indexes - particularly, GIST? ISTM we
might have had a thought that some GIST opclasses but not others would
be able to
On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts between rows and arrays. Now we have a
lot of tools for arrays, and these tools should be used for rows too.
Hello Royce,
Thanks again for testing.
On 2011-10-11 13:55, Royce Ausburn wrote:
Just one small thing: it'd be nice to have an example for cursor declaration
with named parameters. Your patch adds one for opening a cursor, but not for
declaring one.
Declaration of cursors with named
On 11/10/2011, at 11:38 PM, Yeb Havinga wrote:
Declaration of cursors with named parameters is already part of PostgreSQL
(so it is possible to use the parameter names in the cursor query instead of
$1, $2, etc.) and it also already documented with an example, just a few
lines above the
On Mon, Oct 10, 2011 at 10:25:18PM -0700, Jeff Davis wrote:
On Tue, 2011-10-11 at 03:14 +0200, Florian Pflug wrote:
Maybe ranges over discrete types are slightly more likely to be
closed, and ranges over continuous types slightly more likely to
be open. Still, I very much doubt that the
2011/10/11 Robert Haas robertmh...@gmail.com:
On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts between rows and arrays. Now we have a
lot of tools for
sometimes he can use a numeric or int array, sometimes he have to
select text array. Target type is selected by user, and cast fail when
conversion is not possible.
using a some selected type (for array field) allows a processing in plpgsql.
motivation for this feature is simplification and
Hi,
2011-10-11 14:23 keltezéssel, Robert Haas írta:
On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts between rows and arrays. Now we have a
lot of tools for
2011/10/11 Boszormenyi Zoltan z...@cybertec.at:
Hi,
2011-10-11 14:23 keltezéssel, Robert Haas írta:
On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts
On Tue, Oct 11, 2011 at 3:40 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts between rows and arrays. Now we have a
lot of tools for arrays, and these tools should be used for rows too.
2011/10/11 Merlin Moncure mmonc...@gmail.com:
On Tue, Oct 11, 2011 at 3:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possible casts between rows and arrays. Now we have a
lot of tools for
On Oct11, 2011, at 14:43 , David Fetter wrote:
I'd recoil at not having ranges default to left-closed, right-open.
The use case for that one is so compelling that I'm OK with making it
the default from which deviations need to be specified.
The downside of that is that, as Tom pointed out
Robert Haas robertmh...@gmail.com writes:
Have you given any thought to what would be required to support
index-only scans on non-btree indexes - particularly, GIST? ISTM we
might have had a thought that some GIST opclasses but not others would
be able to regurgitate tuples, or maybe even
On Tue, Oct 11, 2011 at 03:20:05PM +0200, Florian Pflug wrote:
On Oct11, 2011, at 14:43 , David Fetter wrote:
I'd recoil at not having ranges default to left-closed,
right-open. The use case for that one is so compelling that I'm
OK with making it the default from which deviations need to
On Tue, Oct 11, 2011 at 8:18 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2011/10/11 Merlin Moncure mmonc...@gmail.com:
On Tue, Oct 11, 2011 at 3:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with
On Tue, Oct 11, 2011 at 5:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I haven't thought as far ahead as how we might get the information
needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
CLASS might be the only way.
Shouldn't it be implemented through additional interface
2011/10/11 Merlin Moncure mmonc...@gmail.com:
On Tue, Oct 11, 2011 at 8:18 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2011/10/11 Merlin Moncure mmonc...@gmail.com:
On Tue, Oct 11, 2011 at 3:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
A current limits of dynamic work
On Mon, Oct 10, 2011 at 1:38 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'm sorry again. I tought it was obvious from the filenames.
I guess I got confused because you re-posted part 2 without the other
parts, and I got mixed up and thought you were reposting part one.
I've committed a
On Oct 7, 2011, at 8:47 PM, Joshua D. Drake wrote:
On 10/07/2011 11:40 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Please find attached a patch implementing a basic version of
index-only scans.
I'm making some progress with this, but I notice what seems like a
missing
Pavel Stehule pavel.steh...@gmail.com writes:
2011/10/11 Robert Haas robertmh...@gmail.com:
On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
What do you think about this idea?
It's a bad one.
Well, a ROW can contain values of different types; an ARRAY can't.
Fujii Masao wrote:
On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus j...@agliodbs.com wrote:
Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
provide parameters solely for recovery. That is difficult
Kevin Grittner wrote:
Joe Conway m...@joeconway.com wrote:
On 10/10/2011 01:52 PM, Gurjeet Singh wrote:
ALTER USER novice SET MIN_VAL OF statement_timeout TO '1';
-- So that the user cannot turn off the timeout
ALTER DATABASE super_reliable SET ENUM_VALS OF synchronous_commit
TO
I can't see a reason why we would use a new WAL record for this,
rather than modify the XLOG_PARAMETER_CHANGE record type which was
created for a very similar reason.
The code would be much simpler if we just extend
XLOG_PARAMETER_CHANGE, so please can we do that?
Sure.
The log
On Mon, Oct 10, 2011 at 3:59 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I do have some concern about whether the performance improvements
from reduced LW locking contention elsewhere in the code may (in
whack-a-mole fashion) cause the percentages to go higher in SSI.
The biggest
On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote:
Certainly not the end of the world, but is the convenience of being
able to write somerange(a, b) instead of somerange(a, b, '[)')
really worth it? I kind of doubt
On Tue, Oct 11, 2011 at 12:09:01PM -0400, Robert Haas wrote:
On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote:
Certainly not the end of the world, but is the convenience of being
able to write somerange(a, b)
On Tue, Oct 11, 2011 at 12:12 PM, David Fetter da...@fetter.org wrote:
Nothing's bad about '[]' per se. What's better, but possibly out of
the reach of our current lexing and parsing system, would be things
like:
[1::int, 10)
That's been discussed before. Aside from the parser issues
On Tue, 2011-10-11 at 12:09 -0400, Robert Haas wrote:
The cure seems worse than the disease. What is so bad about '[]'?
OK, so we stick with the 3-argument form. Do we have a default for the
third argument, or do we scrap it to avoid confusion?
There were some fairly strong objections to using
On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote:
Certainly not the end of the world, but is the convenience of being
able to write somerange(a, b) instead of somerange(a, b, '[)')
really worth it? I kind of doubt that...
You're making a persuasive argument for the latter based
On Tue, Oct 11, 2011 at 12:30 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2011-10-11 at 12:09 -0400, Robert Haas wrote:
The cure seems worse than the disease. What is so bad about '[]'?
OK, so we stick with the 3-argument form. Do we have a default for the
third argument, or do we scrap
Josh Berkus wrote:
It occurs to me that we could really use two things to make it easier to
move copies of database stuff around:
pg_dump -r, which would include a CREATE ROLE for all roles needed to
restore the database (probably without passwords), and
pg_dumpall -r --no-passwords which
Greg Stark wrote:
On Mon, Oct 10, 2011 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My intention was to allow it to consider any covering index. ?You're
thinking about the cost estimate, which is really entirely different.
Is there any reason to consider more than one? I would have
On 10/11/2011 12:40 PM, Bruce Momjian wrote:
Josh Berkus wrote:
It occurs to me that we could really use two things to make it easier to
move copies of database stuff around:
pg_dump -r, which would include a CREATE ROLE for all roles needed to
restore the database (probably without
Robert Haas robertmh...@gmail.com wrote:
I ran my good old pgbench -S, scale factor 100, shared_buffers =
8GB test on Nate Boley's box. I ran it on both 9.1 and 9.2dev,
and at all three isolation levels. As usual, I took the median of
three 5-minute runs, which I've generally found
Andrew Dunstan wrote:
On 10/11/2011 12:40 PM, Bruce Momjian wrote:
Josh Berkus wrote:
It occurs to me that we could really use two things to make it easier to
move copies of database stuff around:
pg_dump -r, which would include a CREATE ROLE for all roles needed to
restore the
On Mon, Oct 10, 2011 at 11:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com wrote:
How do we turn it on/off to allow the overhead to be measured?
User REPEATABLE READ transactions or SERIALIZABLE transactions. The
easiest way, if you're doing it for
On Tue, Oct 11, 2011 at 12:46 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I ran my good old pgbench -S, scale factor 100, shared_buffers =
8GB test on Nate Boley's box. I ran it on both 9.1 and 9.2dev,
and at all three isolation levels. As
On Tue, Oct 11, 2011 at 1:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 10, 2011 at 11:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com wrote:
How do we turn it on/off to allow the overhead to be measured?
User REPEATABLE READ
On Tue, Oct 11, 2011 at 12:43 PM, Bruce Momjian br...@momjian.us wrote:
Greg Stark wrote:
On Mon, Oct 10, 2011 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My intention was to allow it to consider any covering index. ?You're
thinking about the cost estimate, which is really entirely
On Tue, Oct 11, 2011 at 6:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 11, 2011 at 1:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 10, 2011 at 11:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs si...@2ndquadrant.com wrote:
How do we turn it
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Did these transactions write anything? If not, were they
declared to be READ ONLY? If they were, in fact, only reading,
it would be interesting to see what the performance looks like if
the
Simon Riggs si...@2ndquadrant.com wrote:
It's common to find applications that have some transactions
explicitly coded to use SERIALIZABLE mode, while the rest are in
the default mode READ COMMITTED. So common that TPC-E benchmark
has been written as a representation of such workloads.
I
On Tue, 2011-10-11 at 12:40 -0400, Robert Haas wrote:
I think using '[)' is fine. At some level, this is just a question of
expectations. If you expect that int4range(1,4) will create a range
that includes 4, well, you're wrong. Once you get used to it, it will
seem normal, and you'll know
Jeff Davis pg...@j-davis.com writes:
Tom made an observation about '[1,INT_MAX]' thowing an error because
canonicalization would try to increment INT_MAX. But I'm not
particularly disturbed by it. If you want a bigger range, use int8range
or numrange -- the same advice we give to people who
On Tue, Oct 11, 2011 at 12:18:18PM -0400, Robert Haas wrote:
On Tue, Oct 11, 2011 at 12:12 PM, David Fetter da...@fetter.org wrote:
Nothing's bad about '[]' per se. What's better, but possibly out
of the reach of our current lexing and parsing system, would be
things like:
[1::int, 10)
On Tue, Oct 11, 2011 at 8:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/10/11 Robert Haas robertmh...@gmail.com:
On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
What do you think about this idea?
It's a bad one.
Bruce Momjian br...@momjian.us wrote:
Kevin Grittner wrote:
Joe Conway m...@joeconway.com wrote:
On 10/10/2011 01:52 PM, Gurjeet Singh wrote:
ALTER USER novice SET MIN_VAL OF statement_timeout TO '1';
-- So that the user cannot turn off the timeout
ALTER DATABASE super_reliable SET
On Tue, Oct 11, 2011 at 7:08 AM, Royce Ausburn royce...@inomial.com wrote:
I wonder, could the recent work on index only scans pave the way for auto
clustered tables? Consider a wide, mostly insert table with some subset of
columns that I'd like to cluster on. I'm after locality of tuples
On 10/11/2011 11:53 AM, Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
Is this a TODO? We might not want to make work_mem SUSET, but it
would allow administrators to control this.
Well, we've identified a few people who like the idea, but I'm not
sure we have the degree of
Robert Haas robertmh...@gmail.com wrote:
[implement clustered index as a covering index with all columns
which are present in the heap]
I guess we could do that, but I'm not convinced there would be
much benefit.
The traditional way to implement a clustered index is to have the
leaf
On 10/10/11 9:53 PM, Fujii Masao wrote:
Or you think that, to keep the backward compatibility completely,
recovery.conf should be used as not only a configuration file but also a
recovery trigger one and it should be renamed to recovery.done at
the end of recovery?
That's precisely my point.
On Tue, Oct 11, 2011 at 3:02 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
[implement clustered index as a covering index with all columns
which are present in the heap]
I guess we could do that, but I'm not convinced there would be
much
On Sun, Oct 9, 2011 at 06:34, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Oct 8, 2011, at 11:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to fix this by changing the test to examine idx_tup_read
not idx_tup_fetch. Alternatively, we could have the
What is the logic for not dumping passwords but the CREATE ROLE
statement? I don't see how anyone would recognize that behavior as
logical. If you want to add a --no-passwords option to pg_dumpall, that
seems more logical to me.
That's what I'm suggesting.
Incidentally, what's the
Magnus Hagander mag...@hagander.net writes:
On Sun, Oct 9, 2011 at 06:34, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Should we have another counter for heap fetches avoided? Seems like that
could be useful to know.
Hm. I'm hesitant to add another
Josh Berkus wrote:
What is the logic for not dumping passwords but the CREATE ROLE
statement? I don't see how anyone would recognize that behavior as
logical. If you want to add a --no-passwords option to pg_dumpall, that
seems more logical to me.
That's what I'm suggesting.
Florian Pflug f...@phlo.org writes:
On Oct11, 2011, at 14:43 , David Fetter wrote:
I'd recoil at not having ranges default to left-closed, right-open.
The use case for that one is so compelling that I'm OK with making it
the default from which deviations need to be specified.
I agree with
Heikki Linnakangas wrote:
On 11.03.2011 19:41, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 11.03.2011 17:59, Tom Lane wrote:
But that will be fixed during WAL replay.
Not under the circumstances that started the original thread:
1. Backend
On Oct11, 2011, at 21:27 , Robert Haas wrote:
Alternatively, we could try to graft the concept of a self-clustering
table on top of the existing heap implementation. But I'm having
trouble seeing how that would work. The TODO describes it as
something like maintain CLUSTER ordering, but
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Well, we've identified a few people who like the idea, but I'm not
sure we have the degree of consensus we normally look for before
putting something on the TODO list. After the discussion on this
thread, are there still any *objections* to
Andrew Dunstan and...@dunslane.net writes:
On 10/11/2011 12:40 PM, Bruce Momjian wrote:
Josh Berkus wrote:
pg_dumpall -r --no-passwords which would dump the roles but without
CREATE PASSWORD statements. This would be useful for cloning databases
for use in Dev, Test and Staging, where you
On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
If you alter the default_transaction_isolation then you will break
applications like this, so it is not a valid way to turn off SSI.
I don't follow you here. What would break? In what fashion? Since
the
Robert Haas:
Serializable mode is much slower on this test, though. On
REL9_1_STABLE, it's about 8% slower with a single client. At 8
clients, the difference rises to 43%, and at 32 clients, it's 51%
slower.
Bummer. Thanks for putting some numbers out there; glad I was able
to jump start a
Robert Haas wrote:
And it seems to me that there could easily be format changes that
would make sense for particular cases, but not across the board,
like:
- index-organized tables (heap is a btree, and secondary indexes
reference the PK rather than the TID; this is how MySQL does it, and
Oracle
If the normal default_transaction_isolation = read committed and all
transactions that require serializable are explicitly marked in the
application then there is no way to turn off SSI without altering the
application. That is not acceptable, since it causes changes in
application behaviour
On Tue, Oct 11, 2011 at 5:45 AM, Greg Stark st...@mit.edu wrote:
On Mon, Oct 10, 2011 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My intention was to allow it to consider any covering index. You're
thinking about the cost estimate, which is really entirely different.
Is there any reason
On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian br...@momjian.us wrote:
As much as I appreciate Simon's work in this area, I think we are still
unclear if keeping backward-compatibility is worth the complexity
required for future users. Historically we have been bold in changing
Simon Riggs wrote:
On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian br...@momjian.us wrote:
As much as I appreciate Simon's work in this area, I think we are still
unclear if keeping backward-compatibility is worth the complexity
required for future users. ?Historically we have been bold in
On 10/11/2011 04:19 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 10/11/2011 12:40 PM, Bruce Momjian wrote:
Josh Berkus wrote:
pg_dumpall -r --no-passwords which would dump the roles but without
CREATE PASSWORD statements. This would be useful for cloning databases
for
On Tue, Oct 11, 2011 at 9:21 PM, Greg Sabino Mullane g...@endpoint.com wrote:
Simon Riggs:
Most apps use mixed mode serializable/repeatable read and therefore
can't be changed by simple parameter. Rewriting the application isn't
a sensible solution.
I think it's clear that SSI should have
The trouble is that if we VACUUM and then ANALYZE, we'll often get
back a value very close to 100%, but then the real value may diminish
quite a bit before the next auto-analyze fires. I think if we can
figure out what to do about that problem we'll be well on our way...
It's not so much an
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
If the normal default_transaction_isolation = read committed and all
transactions that require serializable are explicitly marked in the
application then there is no way to turn off SSI without altering the
application. That is not
Simon Riggs wrote:
On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
If you alter the default_transaction_isolation then you will break
applications like this, so it is not a valid way to turn off SSI.
I don't follow you here. ?What would break? ?In
Alexander Korotkov aekorot...@gmail.com writes:
On Tue, Oct 11, 2011 at 5:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I haven't thought as far ahead as how we might get the information
needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
CLASS might be the only way.
Shouldn't
Josh Berkus wrote:
Acording the docs, I assume -r is only roles, while -g includes
tablespace, so what you want is already available in pg_dumpall.
No, it's not. You don't seem to be actually reading any of my proposals.
(1) I cannot produce a single file in custom dump format which
On Tue, Oct 11, 2011 at 9:28 PM, Bruce Momjian br...@momjian.us wrote:
Standard conforming strings
was tricky because it was more user-facing, or certainly SQL-facing.
Why is SQL more important than backup?
There is no good reason to do this so quickly.
--
Simon Riggs
Simon Riggs si...@2ndquadrant.com wrote:
Greg Sabino Mullane g...@endpoint.com wrote:
Eh? It has an off switch: repeatable read.
You mean: if we recode the application and retest it, we can get
it to work same way as it used to.
To most people that is the same thing as it doesn't work
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Adding the information visible at the right places is a fun
project in itself, too :)
I was thinking a couple new columns in pg_settings (and what backs
it) would be the main thing, but I
On Tue, Oct 11, 2011 at 04:32:45PM -0400, Bruce Momjian wrote:
...
Simon seems to value backward-compatibility more than the average
hackers poster. The lack of complaints about 9.1 I think means that the
hackers decision of _not_ providing a swich was the right one.
I wouldn't go that far:
On Wed, Oct 12, 2011 at 12:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm. I had been supposing that lossless compress functions would just be
no-ops. If that's not necessarily the case then we might need something
different from the opclass's decompress function to get back the
original
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The underlying issue here is whether objects dependent on an extension
member should have direct dependencies on the extension too, and if not,
how do we prevent that? The
On Tue, Oct 11, 2011 at 9:32 PM, Bruce Momjian br...@momjian.us wrote:
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
If the normal default_transaction_isolation = read committed and all
transactions that require serializable are explicitly marked in the
application then there
Acording the docs, I assume -r is only roles, while -g includes
tablespace, so what you want is already available in pg_dumpall.
No, it's not. You don't seem to be actually reading any of my proposals.
(1) I cannot produce a single file in custom dump format which includes
both a single
Simon Riggs si...@2ndquadrant.com writes:
There is no off switch and there should be.
As Greg said, that ship has sailed. I believe that we specifically
discussed the notion of an off switch via a GUC or similar during
9.1 development, and rejected it on the grounds that GUCs changing
Simon Riggs wrote:
On Tue, Oct 11, 2011 at 9:28 PM, Bruce Momjian br...@momjian.us wrote:
Standard conforming strings
was tricky because it was more user-facing, or certainly SQL-facing.
Why is SQL more important than backup?
Because the percentage of database users it affects is
Greg Sabino Mullane g...@endpoint.com wrote:
Kevin Grittner:
Did these transactions write anything? If not, were they
declared to be READ ONLY? If they were, in fact, only reading,
it would be interesting to see what the performance looks like if
the recommendation to use the READ
Tom Lane t...@sss.pgh.pa.us writes:
I haven't thought as far ahead as how we might get the information
needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
CLASS might be the only way.
It looks to me like it's related to the RECHECK property. Maybe it's
just too late, though.
Simon Riggs wrote:
Simon seems to value backward-compatibility more than the average
hackers poster. ?The lack of complaints about 9.1 I think means that the
hackers decision of _not_ providing a swich was the right one.
So its been out 1 month and you think that is sufficient time for us
1 - 100 of 127 matches
Mail list logo
