On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
Any chance of getting the fix in patch format so we could test it on
this system?
On Thu, Nov 10, 2011 at 10:19:02PM +0100, Dimitri Fontaine wrote:
Now the aim would be to be able to implement the operation you describe
by using the new segment map, which is an index pointing to sequential
ranges of on-disk blocks where the data is known to share a common key
range over the
Hello Hackers.
I attached trivial patch.
Foreign table either defines row type. I simply added this type to
hardcoded check.
I faced this limitation while developing www fdw feature
(http://wiki.postgresql.org/wiki/WWW_FDW).
--
Alexander Soudakov
Software Developer
email: cyga...@gmail.com
Martijn van Oosterhout klep...@svana.org writes:
While I agree that explicit partitioning is somewhat of a hack, it's a
really useful hack. But for me the most important use of partitioning
is dropping a billion rows efficiently and getting the disk space
back.
Right. The only way to make
Kyotaro HORIGUCHI horiguchi.kyot...@oss.ntt.co.jp writes:
Hello. This message is a proposal of a pair of patches that
enables the memory allocator for PGresult in libpq to be
replaced.
Since there seems to be rough consensus that something like this would
be a good idea, I looked more closely
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 11.11.2011 11:18, Kyotaro HORIGUCHI wrote:
For these reasons, I propose to make allocators for PGresult
replaceable.
You could use the resource owner mechanism to track them.
BTW, I just thought of a potentially fatal
On 12/11/2011 07:36, Robert Haas wrote:
On Sat, Nov 12, 2011 at 12:48 AM, Tom Lanet...@sss.pgh.pa.us wrote:
AIUI Kyotaro-san is just suggesting that the app should be able to
provide a substitute malloc function for use in allocating PGresult
space (and not, I think, anything else that libpq
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Well, loading data in a form whereby the application can access it
without going through the PGresult accessor functions would be an
entirely different (and vastly larger) project.
Looking through the thread, I agree that it's a different thing than
On Nov11, 2011, at 19:17 , Tom Lane wrote:
But frankly I do not like any of these proposals. Making fundamental
changes in long-established semantics in the name of squeezing out a few
cycles is the wrong way to design software.
Hm, then maybe this is one of the things to put onto the next
On Wed, Nov 9, 2011 at 6:22 PM, Florian Pflug f...@phlo.org wrote:
On Nov9, 2011, at 23:53 , Daniel Farina wrote:
I think a novice user would be scared half to death: I know I was the
first time. That's not a great impression for the project to leave
for what is not, at its root, a vast
Alexander Soudakov cyga...@gmail.com writes:
Foreign table either defines row type. I simply added this type to
hardcoded check.
Yeah, I think this was just an oversight. (You missed a spot in
plpgsql_parse_cwordtype, though.) Patch applied.
regards, tom lane
--
I notice that there's some weird info coming out of the system columns
on any FDW:
test=# select tableoid, ctid, xmin, xmax, cmin, cmax, * from dict limit 12;
tableoid | ctid | xmin |xmax| cmin | cmax | words
Thom Brown t...@linux.com writes:
So the ctid is always 2^32-1. Bit weird, but probably explainable.
See ItemPointerSetInvalid.
But xmin on the file_fdw result is odd. Why are these all over the
place?
heap_form_tuple initializes the t_choice fields as though for a tuple
Datum, and
On 13 November 2011 00:38, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
But xmin on the file_fdw result is odd. Why are these all over the
place?
heap_form_tuple initializes the t_choice fields as though for a tuple
Datum, and file_fdw doesn't change it.
Just a
On Sat, Nov 12, 2011 at 5:09 PM, Florian Pflug f...@phlo.org wrote:
On Nov11, 2011, at 19:17 , Tom Lane wrote:
But frankly I do not like any of these proposals. Making fundamental
changes in long-established semantics in the name of squeezing out a few
cycles is the wrong way to design
On 08/26/2011 05:11 PM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
The --section=data --section=indexes proposal seems very reasonable to
me -- more so than --sections='data indexes'.
+1 ... not only easier to code and less squishily defined, but more like
the existing
On Fri, Nov 11, 2011 at 10:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Tom, in that earlier thread you said you'd be doing something in this
release about that. Can you say more about what that was, and will you
be doing it still?
17 matches
Mail list logo
