Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 7, 2011 at 4:06 PM, Bruce Momjian br...@momjian.us wrote:
I would just fix it in head.
That just seems weird. Either it's cheap enough not to matter (in
which case there's no reason to revert that change at all) or it's
expensive enough
Greg Stark st...@mit.edu writes:
On Fri, Oct 7, 2011 at 10:10 PM, Merlin Moncure mmonc...@gmail.com wrote:
Facts are not subject to copyright but compilations can be.
I know it's popular for engineers to play lawyer and I've been guilty
of it on many an occasion. But in this case I think
2011/10/8 Noah Misch n...@leadboat.com:
On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
My preference is still also WITH(security_barrier=...) syntax.
The arguable point was the behavior when a view is replaced without
explicit WITH clause;
whether we should consider it was
On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
The first thing caught my eye in existing GiST code is idea of
subtype_float. float8 has limited precision and can't respresent, for
example, varlena values good enough. Even if we have large int8 value
we can loose lower bits, but
Bruce Momjian wrote:
OK, I have modified the postmaster in PG 9.2 to allow output of the data
directory, and modified pg_ctl to use that, so starting in PG 9.2 pg_ctl
will work cleanly for config-only directories.
I will now work on pg_upgrade to also use the new flag to find the data
Julien Tachoires 10/07/11 10:17 AM
Here's a patch to allow TOAST tables to be moved to a different
tablespace. This item has been picked up from the TODO list.
Main idea is to consider that a TOAST table can have its own
tablespace.
Thanks for the patch. Please add this to the open
On Sat, Oct 8, 2011 at 1:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
The first thing caught my eye in existing GiST code is idea of
subtype_float. float8 has limited precision and can't respresent, for
example, varlena values
I notice that several members of the buildfarm have been consistently
showing the same regression test failure since the index-only scans
patch went in:
***
/home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out
Sat Oct 8 03:20:05 2011
---
On 10/07/2011 11:02 PM, Greg Stark wrote:
All that said I think this is far murkier than you all seem to think.
Copyright law is one of the most complex areas of the law and this is
one of the least well defined parts of copyright law.
Hi Greg:
I don't think we all think this issue is
The obvious typos:
,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) *
| (may use pg_attribute.attnotnull on t1, t2, is I didn't see the 'create's.
(may use pg_attribute.attnotnull on t1, t2, if I didn't see the 'create's.
| Now, for this statement, I can easily identify non-nullable
Hello all,
While working on an application I have been developing for about two
years now, I have come across a base-limitation in PostgreSQL for three
separate problems. I was talking with other members of the community
recently and they agreed that the issue has some merit so I thought I
2011/10/8 Tom Lane t...@sss.pgh.pa.us:
I notice that several members of the buildfarm have been consistently
showing the same regression test failure since the index-only scans
patch went in:
***
/home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out
Sat Oct
I wrote:
Robert Haas robertmh...@gmail.com writes:
Not really. We have detected a small performance regression when both
heap and index fit in shared_buffers and an index-only scan is used.
I have a couple of ideas for improving this. One is to store a
virtual tuple into the slot instead of
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
2011/10/8 Tom Lane t...@sss.pgh.pa.us:
The diff indicates that the idx_scan count advanced but idx_tup_fetch
did not, which is not so surprising here because tenk2 hasn't been
modified in some time. If the
On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote:
2011/10/8 Noah Misch n...@leadboat.com:
On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
My preference is still also WITH(security_barrier=...) syntax.
The arguable point was the behavior when a view is replaced
On Sat, 2011-10-08 at 18:43 +0400, Alexander Korotkov wrote:
I meant that penalty can be determined as sum of difference of old and
new bounds of range, i.e. penalty = subtype_diff_float(new_lower,
old_lower) + subtype_diff_float(old_upper, new_upper).
When we insert [100,200) into
Josh j...@schemaverse.com writes:
[ unhappy about users being able to freely adjust work_mem etc ]
Really, if you're letting users issue arbitrary SQL queries, there
simply isn't any way to prevent them from beating your server into
the ground. I don't think that inserting a hack to prevent
I tried to review the Optimizing box_penalty patch:
https://commitfest.postgresql.org/action/patch_view?id=600
as posted here:
http://archives.postgresql.org/message-id/4e088690.5080...@enterprisedb.com
The patch no longer applies to source code, due to other recent GiST
changes. Parts of
I'll point to rather different reasoning...
Libpq is not returning tables, or relations, for that matter, but rather the
results of queries.
It is reasonable to expect to know which attributes of a table are or are
not nullable, and that is commonly available as an attribute of
pg_attribute,
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 test force
enable_indexonlyscan off. Thoughts?
No preference.
Should we have another counter for heap
On Oct 8, 2011, at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to do the last part immediately, since there's a
performance argument for it, and then work on revising the executor
implementation.
Sounds great. Thanks for working on this.
...Robert
--
Sent via pgsql-hackers
On Sun, Oct 2, 2011 at 12:05 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote:
Looking at the patch, I noticed that it's possible to specify the default
boundaries ([], [), (] or ()) per individual float type with the
DEFAULT_FLAGS clause of CREATE
On Sat, 2011-10-08 at 12:44 -0700, Jeff Janes wrote:
When I apply this to head, make check fails with:
create type textrange_en_us as range(subtype=text, collation=en_US);
+ ERROR: collation en_US for encoding SQL_ASCII does not exist
Is this a problem? e.g. will it break the
On Tue, Sep 27, 2011 at 1:33 AM, Fujii Masao masao.fu...@gmail.com wrote:
Though there is still ongonig discussion, since there is no objection about
the above two changes, I revised the patch that way. And I fixed the minor
bug handling the default value of recovery_target_timeline wrongly.
It seems that in order to create an object in a given schema, I must
have been granted create privilege on the schema. But in order to drop
that object I require usage privilege.
This means that with the right privilege settings I can create objects
that I cannot subsequently drop, or can drop
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 test force
enable_indexonlyscan off. Thoughts?
No preference.
26 matches
Mail list logo
