On 05.10.2011 15:59, Alexander Korotkov wrote:
Path without allocating extra bytes is attached.
I run some more detailed tests on geonames and two smaller datasets from
rtreeportal.org.
Ok, thanks. Looks good to me now, so committed.
--
Heikki Linnakangas
EnterpriseDB
On Thu, Oct 6, 2011 at 11:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 05.10.2011 15:59, Alexander Korotkov wrote:
Path without allocating extra bytes is attached.
I run some more detailed tests on geonames and two smaller datasets from
rtreeportal.org.
Ok,
Hi Alex,
I didn't care for the changes to gram.y so I reworked it a bit so we
now pass is_only to AddRelationNewConstraint() (like we do with
is_local). Seemed simpler but maybe I missed something. Comments?
Hmmm, your patch checks for a constraint being only via:
!recurse
We are working on the hackers documentation, hope to submit it before my
himalaya track.
Oleg
On Sun, 2 Oct 2011, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 06.09.2011 20:34, Oleg Bartunov wrote:
Here is the latest spgist patch, which has all planned
Until recently, when using GNU tar for creating base backups, you'd have
to ignore file changed as we read it and file removed before we read
it warnings, which would require a bit of craftiness if you wanted to
hide these messages while still seeing other warnings and errors from
tar.
As of GNU
On 06.10.2011 11:22, Alexander Korotkov wrote:
Thanks. I'm going to continue work on application of this split method in
following areas:
1) range types
2) seg contrib module
3) cube contrib module (there situation is not so easy, probably some
heuristic of split method selection would be
On 25.09.2011 19:01, Robert Haas wrote:
On Wed, Sep 14, 2011 at 6:52 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Why do you need new WAL replay routines? Can't you just use the existing
XLOG_HEAP_NEWPAGE support?
By any large, I think we should be avoiding
On Thu, Oct 6, 2011 at 7:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
A regular heap_insert record leaves out a lot of information that can be
deduced at replay time. It can leave out all the headers, including just the
null bitmap + data. In addition to that, there's
Hello
a order of on result in foreign server test depends on locales.
This fix renames a 'cs' identifier to 's0' identifier
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Oct5, 2011, at 15:30 , Magnus Hagander wrote:
When walsender calls out to do_pg_stop_backup() (during base backups),
it is not possible to terminate the process with a SIGTERM - it
requires a SIGKILL. This can leave unkillable backends for example if
archive_mode is on and archive_command
On Wed, Oct 5, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 5, 2011 at 5:53 PM, Alex Hunsaker bada...@gmail.com wrote:
tldr:
Seems to be broken by
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4da99ea4231e3d8bbf28b666748c1028e7b7d665
:
commit
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Oct 3, 2011 at 11:04 PM, Bruce Momjian br...@momjian.us wrote:
OK, here is a patch that adds a -C option to the postmaster so any
config variable can be dumped, even while the server is
Initial Review for patch:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00744.php
Submission review
The patch is in context diff format and applies cleanly to the git master. The
patch includes an update to regression tests. The regression tests pass. The
patch does not include
On Wed, Oct 5, 2011 at 1:19 AM, Fujii Masao masao.fu...@gmail.com wrote:
While the system is idle, we skip duplicate checkpoints for some
reasons. But when wal_level is set to hot_standby, I found that
checkpoints are wrongly duplicated even while the system is idle.
The cause is that
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Yeah. I think the only sensible way to do this would be to provide an
operating mode for the postgres executable that would just parse the
config file and spit
On 06.10.2011 15:11, Robert Haas wrote:
On Thu, Oct 6, 2011 at 7:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
A regular heap_insert record leaves out a lot of information that can be
deduced at replay time. It can leave out all the headers, including just the
null
On Wed, Oct 5, 2011 at 6:19 AM, Fujii Masao masao.fu...@gmail.com wrote:
While the system is idle, we skip duplicate checkpoints for some
reasons. But when wal_level is set to hot_standby, I found that
checkpoints are wrongly duplicated even while the system is idle.
The cause is that
Simon Riggs si...@2ndquadrant.com writes:
The current idea is that if there has been no activity then we skip
checkpoint. But all it takes is a single WAL record and off we go with
another checkpoint. If there hasn't been much WAL activity, there is
not much point in having another checkpoint
On Wed, Aug 31, 2011 at 4:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 2, 2010 at 12:17 PM, Tom Lane t...@postgresql.org wrote:
Log Message:
---
Ensure that contrib/pgstattuple functions respond to cancel interrupts
reasonably promptly, by adding CHECK_FOR_INTERRUPTS in
Hello all,
Thank you for all your responses to my inquiry.
We are aware that this application version 8.2.x is pretty old and PostgreSQL
will stop releasing updates for the 8.2.X in December 2011.
http://www.postgresql.org/docs/8.2/interactive/release-8-2-22.html
We also confirmed this
Hi Robert,
Great. I will submit that for the response.
Thanks again for your quick assistance.
Regards,
Seiko Ishida
Microsoft ISV Readiness, EcoSystem Engineering Team
Program Manager
v-sei...@microsoft.commailto:v-sei...@microsoft.com
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent:
On Oct 5, 2011, at 7:36 PM, Robert Haas wrote:
The open commitfest? Even if its an important bug fix that should be
backpatched?
Considering that the issue appears to have been ignored from
mid-February until early October, I don't see why it should now get to
jump to the head of the
Royce Ausburn royce...@inomial.com writes:
Initial Review for patch:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00744.php
The patch adds a means of specifying named cursor parameter arguments in
pg/plsql.
Do we want that?
I very rarely use pg/plsql, so I won't
On Thu, Oct 6, 2011 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The current idea is that if there has been no activity then we skip
checkpoint. But all it takes is a single WAL record and off we go with
another checkpoint. If there hasn't been much
On Thu, Oct 6, 2011 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Royce Ausburn royce...@inomial.com writes:
Initial Review for patch:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00744.php
The patch adds a means of specifying named cursor parameter arguments in
pg/plsql.
Robert Haas robertmh...@gmail.com writes:
I'm not entirely sure I understand the rationale, though. I mean, if
very little has happened since the last checkpoint, then the
checkpoint will be very cheap. In the totally degenerate case Fujii
Masao is reporting, where absolutely nothing has
Robert Haas robertmh...@gmail.com writes:
+1. However, if that's the route we're traveling down, I think we had
better go ahead and remove the one remaining = operator from hstore
in 9.2:
Fair enough.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not entirely sure I understand the rationale, though. I mean, if
very little has happened since the last checkpoint, then the
checkpoint will be very cheap. In the totally
On Thu, Oct 6, 2011 at 02:42, Nikhil Sontakke nikkh...@gmail.com wrote:
Hi Alex,
I didn't care for the changes to gram.y so I reworked it a bit so we
now pass is_only to AddRelationNewConstraint() (like we do with
is_local). Seemed simpler but maybe I missed something. Comments?
Hmmm, your
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I think the point is that a totally idle database should not
continue to emit WAL, not even at a slow rate. There are also
power-consumption objections to allowing the checkpoint process
to fire up to no purpose.
On Thu, Oct 6, 2011 at 5:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
The current idea is that if there has been no activity then we skip
checkpoint. But all it takes is a single WAL record and off we go with
another checkpoint. If there hasn't been much
On Oct 6, 2011, at 9:46 AM, Tom Lane wrote:
+1. However, if that's the route we're traveling down, I think we had
better go ahead and remove the one remaining = operator from hstore
in 9.2:
Fair enough.
Would it then be added as an alias for := for named function parameters? Or
would
David E. Wheeler da...@kineticode.com writes:
On Oct 6, 2011, at 9:46 AM, Tom Lane wrote:
+1. However, if that's the route we're traveling down, I think we had
better go ahead and remove the one remaining = operator from hstore
in 9.2:
Fair enough.
Would it then be added as an alias for
On Oct 6, 2011, at 10:37 AM, Tom Lane wrote:
Would it then be added as an alias for := for named function parameters? Or
would that come still later?
Once we do that, it will be impossible not merely deprecated to use =
as an operator name. I think that has to wait at least another
David E. Wheeler da...@kineticode.com writes:
Would it then be added as an alias for := for named function parameters? Or
would that come still later?
Once we do that, it will be impossible not merely deprecated to use =
as an operator name. I think that has to wait at least another release
On Oct 6, 2011, at 10:46 AM, Tom Lane wrote:
Okay. I kind of like := so there's no rush AFAIC. :-)
Hmm ... actually, that raises another issue that I'm not sure whether
there's consensus for or not. Are we intending to keep name := value
syntax forever, as an alternative to the standard
On Thu, Oct 6, 2011 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Would it then be added as an alias for := for named function parameters?
Or would that come still later?
Once we do that, it will be impossible not merely deprecated to use =
as
Simon Riggs si...@2ndquadrant.com writes:
Do we want this backpatched? If so, suggest just 9.1 and 9.0?
-1 for backpatching; it's more an improvement than a bug fix.
In any case, I think we still need to respond to the point Kevin made
about how to tell an idle master from broken replication.
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think the point is that a totally idle database should not continue to
emit WAL, not even at a slow rate. There are also power-consumption
objections to allowing the checkpoint
My understanding is that libpq does not allow one to find if a result
set column is nullable.
Is this right?
(I know how to get a table column nullability information from
pg_attribute.attnotnull, but when coding around the libpq API:
* Is, OMG, ugly.
* Doesn't cover the arbitrary SELECT
On 06.10.2011 20:58, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 12:44 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think the point is that a totally idle database should not continue to
emit WAL, not even at a slow rate. There are also power-consumption
On Thu, Oct 6, 2011 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Do we want this backpatched? If so, suggest just 9.1 and 9.0?
-1 for backpatching; it's more an improvement than a bug fix.
OK, works for me.
In any case, I think we still need to
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Do we want this backpatched? If so, suggest just 9.1 and 9.0?
-1 for backpatching; it's more an improvement than a bug fix.
In any case, I think we still need to respond to the point
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that the way to deal with that is not to force out
useless WAL data, but to add some sort of explicit I'm alive heartbeat
signal to the walsender/walreceiver
Hi.
I plan to extend file_fdw wrapper. I will add options to foreign
server: encoding, format, header, delimiter, dir.
And i have some asks:
- it's better to change name of extension or not
- other suggestions
--
pasman
--
Sent via pgsql-hackers mailing list
On Thu, Oct 6, 2011 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 6, 2011 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that the way to deal with that is not to force out
useless WAL data, but to add some sort of
Simon Riggs si...@2ndquadrant.com wrote:
I foresee a function that tells you the delay based on a protocol
message of 'k' for keepalive.
If the delay you mention is basically a ping time or something
similar, that would answer the need I've been on about. We need to
know, based on access to
Robert Haas robertmh...@gmail.com writes:
Please find attached a patch implementing a basic version of
index-only scans. This patch is the work of my colleague Ibrar Ahmed
and myself, and also incorporates some code from previous patches
posted by Heikki Linnakanagas.
I'm starting to review
Hi, Jeff!
Heikki has recently commited my patch about picksplit for GiST on points and
boxes:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f3bd86843e5aad84585a57d3f6b80db3c609916
I would like to try this picksplit method on ranges. I believe that it might
be much more
On Thu, Oct 6, 2011 at 7:18 PM, Robert Haas robertmh...@gmail.com wrote:
As of 9.1, we already have something very much like this, in the
opposite direction.
Yes Robert, I wrote it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On Thu, Oct 6, 2011 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Please find attached a patch implementing a basic version of
index-only scans. This patch is the work of my colleague Ibrar Ahmed
and myself, and also incorporates some code from
On Thu, Oct 6, 2011 at 14:34, Florian Pflug f...@phlo.org wrote:
On Oct5, 2011, at 15:30 , Magnus Hagander wrote:
When walsender calls out to do_pg_stop_backup() (during base backups),
it is not possible to terminate the process with a SIGTERM - it
requires a SIGKILL. This can leave unkillable
On Thu, Oct 6, 2011 at 04:22, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 5, 2011 at 10:30 PM, Magnus Hagander mag...@hagander.net wrote:
When walsender calls out to do_pg_stop_backup() (during base backups),
it is not possible to terminate the process with a SIGTERM - it
requires a
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 building
2011/10/6 Robert Haas robertmh...@gmail.com:
On Thu, Oct 6, 2011 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Would it then be added as an alias for := for named function parameters?
Or would that come still later?
Once we do that, it will be
On Thu, Oct 6, 2011 at 1:02 PM, Alex Goncharov
alex-goncha...@comcast.net wrote:
My understanding is that libpq does not allow one to find if a result
set column is nullable.
Is this right?
(I know how to get a table column nullability information from
pg_attribute.attnotnull, but when
On 6 October 2011 21:11, Tom Lane t...@sss.pgh.pa.us 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
,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) *
| My understanding is that libpq does not allow one to find if a result
| set column is nullable.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why aren't you using PQgetisnull()?
This function is not about the nullability of a column
On Thu, Oct 6, 2011 at 3:22 PM, Alex Goncharov
alex-goncha...@comcast.net wrote:
,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) *
| My understanding is that libpq does not allow one to find if a result
| set column is nullable.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why
On Oct6, 2011, at 22:38 , Merlin Moncure wrote:
On Thu, Oct 6, 2011 at 3:22 PM, Alex Goncharov
alex-goncha...@comcast.net wrote:
,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) *
| My understanding is that libpq does not allow one to find if a result
| set column is nullable.
,---
On Thu, Oct 6, 2011 at 4:16 PM, Florian Pflug f...@phlo.org wrote:
Sure, but there are still a lot of cases where the database could deduce
(quite easily) that a result column cannot be null. Other databases do
that - for example, I believe to remember that Microsoft SQL Server preserves
NOT
On Oct6, 2011, at 21:48 , Magnus Hagander wrote:
The question is, should we do more? To me, it'd make sense to terminate
a backend once it's connection is gone. We could, for example, make
pq_flush() set a global flag, and make CHECK_FOR_INTERRUPTS handle a
broken connection that same way as a
,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) *
| My understanding is that libpq does not allow one to find if a result
| set column is nullable.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why aren't you using PQgetisnull()?
,--- I/Alex (Thu, 06 Oct 2011 16:22:28 -0400) *
|
On 10/06/2011 06:02 PM, Alex Goncharov wrote:
(Look, I appreciate anybody's reply and readiness to help, but if you
have a limited expertise in the subject area, why bother replying?)
People are trying to help you. Please be a little less sensitive.
Sneering at Merlin is not likely to
On Oct7, 2011, at 00:02 , Alex Goncharov wrote:
,--- Florian Pflug (Thu, 6 Oct 2011 23:16:53 +0200) *
| Sure, but there are still a lot of cases where the database could deduce
| (quite easily) that a result column cannot be null.
Right. Of course. I can do it in 'psql'.
For the result
Alex Goncharov wrote:
,--- Merlin Moncure (Thu, 6 Oct 2011 16:28:56 -0500) *
| hm, good point. not sure how it's useful though. I suppose an
| application could leverage that for validation purposes, but that's a
| stretch I think.
,--- You/Florian (Fri, 7 Oct 2011 01:00:40 +0200) *
| On Oct7, 2011, at 00:02 , Alex Goncharov wrote:
| ,--- Florian Pflug (Thu, 6 Oct 2011 23:16:53 +0200) *
| | Sure, but there are still a lot of cases where the database could deduce
| | (quite easily) that a result column cannot be
,--- You/Bruce (Thu, 6 Oct 2011 19:09:16 -0400 (EDT)) *
| (Look, I appreciate anybody's reply and readiness to help, but if you
| have a limited expertise in the subject area, why bother replying?)
|
| FYI, I see 867 Postgres posts mentioning Merlin Moncure in the past
| year:
|
|
On Friday, October 07, 2011 01:42:13 AM Alex Goncharov wrote:
,--- You/Florian (Fri, 7 Oct 2011 01:00:40 +0200) *
| On Oct7, 2011, at 00:02 , Alex Goncharov wrote:
| ,--- Florian Pflug (Thu, 6 Oct 2011 23:16:53 +0200) *
|
| | Sure, but there are still a lot of cases where the
The obvious typos (sorry if this is a duplicate message, I sent the
first one from a wrong address):
,--- 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
,--- You/Andres (Fri, 7 Oct 2011 02:28:30 +0200) *
| a lot of cases where the database could deduce (quite easily) that a
| result column cannot be null
| Could you quickly explain what exactly you want that information for? Just
| because it has been done before doesn't necessarily mean
Alex Goncharov alex-goncha...@comcast.net schrieb:
,--- You/Andres (Fri, 7 Oct 2011 02:28:30 +0200) *
| a lot of cases where the database could deduce (quite easily) that
a
| result column cannot be null
| Could you quickly explain what exactly you want that information for?
Just
|
,--- You/anara...@anarazel.de (Fri, 07 Oct 2011 02:54:39 +0200) *
|
| Given a SELECT (or possibly, simpler, a table name), tell me which
| columns are non-nullable?
| That doesnt explain why it's needed.
It's needed for some meta analysis. That's as much as I can say.
| To get
On Oct7, 2011, at 01:42 , Alex Goncharov wrote:
Right: but for (most?) every SELECT, one can logically deduce whether
it can be guaranteed that a given column will never have a NULL value.
Since in a given SELECT, the result column are a combination of either
other columns, or expressions,
(2011/10/07 3:39), pasman pasmański wrote:
Hi.
I plan to extend file_fdw wrapper. I will add options to foreign
server: encoding, format, header, delimiter, dir.
+1 for existing options. Using foreign server options as default would
make definition of file_fdw foreign tables very simple.
,--- You/Florian (Fri, 7 Oct 2011 03:21:23 +0200) *
| Sure. Deducing nullability isn't a hard problem, at least not if it's
| OK to simply say nullable if things get too complex.
Yes.
| And in PostgreSQL, this could be done by combining
|
| (1) Oid PQftable(const PGresult *res, int
Bruce Momjian wrote:
I will now work on pg_upgrade to also use the new flag to find the data
directory from a config-only install. However, this is only available
in PG 9.2, and it will only be in PG 9.3 that you can hope to use this
feature (if old is PG 9.2 or later). I am afraid the
On Wed, Oct 5, 2011 at 5:14 PM, Marti Raudsepp ma...@juffo.org wrote:
I think you intended to use the Waiting on Author status -- that
leaves the commitfest entry open. I will re-open the commitfest entry
myself, I hope that's OK.
No worries, and yeah, I picked the wrong checkbox. :)
Here is
Forgive my ignorance -- do I need to be doing anything else now seeing as I
started the review?
On 07/10/2011, at 7:15 AM, Pavel Stehule wrote:
2011/10/6 Robert Haas robertmh...@gmail.com:
On Thu, Oct 6, 2011 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler
On Thu, Oct 6, 2011 at 07:24, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 5, 2011 at 10:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 5, 2011 at 5:53 PM, Alex Hunsaker bada...@gmail.com wrote:
tldr:
Seems to be broken by
On Thu, 2011-10-06 at 23:26 +0400, Alexander Korotkov wrote:
Hi, Jeff!
Heikki has recently commited my patch about picksplit for GiST on
points and boxes:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7f3bd86843e5aad84585a57d3f6b80db3c609916
I would like to try this
Thank you for reviewing.
The new version of this patch is attached to this message.
But it seems to me that if the datatype is BYTEAOID then
there's no need to restore anything at all, because we're not
going to call pg_mbcliplen() in that case anyway. So I think
the logic here can be
82 matches
Mail list logo
