On Fri, Nov 11, 2011 at 10:04 PM, Tom Lane wrote:
> Simon Riggs 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?
>
> http://git.postgresql.org/gitweb/?p=postgresql.git&a
On 08/26/2011 05:11 PM, Tom Lane wrote:
Alvaro Herrera 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 precedent for other pg
On Sat, Nov 12, 2011 at 5:09 PM, Florian Pflug 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 software.
>
>
On 13 November 2011 00:38, Tom Lane wrote:
> Thom Brown 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 couple hours ago I was won
Thom Brown 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 file_fdw doesn't ch
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
--++--++---+---+--
Alexander Soudakov 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
--
Sent via pgsql-hack
On Wed, Nov 9, 2011 at 6:22 PM, Florian Pflug 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 defect,
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
* 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
w
On 12/11/2011 07:36, Robert Haas wrote:
On Sat, Nov 12, 2011 at 12:48 AM, Tom Lane 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 allocates internally
Heikki Linnakangas 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 objection to making PGresult
allocatio
Kyotaro HORIGUCHI 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 at the details of the patch.
Martijn van Oosterhout 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 that speedy i
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
sky
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
On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > Any chance of getting the fix in patch format so we could test it on
> > this system?
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
hi
jus
17 matches
Mail list logo
