Hello, Thank you for suggestions.
> > This patch reduces run time of such queries by 45% when result
> > recored has 30 columns and seems to have no harm for performance.
>
> This patch seems quite unsafe to me: it's not generally okay for
> a plan node to return a slot that doesn't belong to it,
I looked into why buildfarm member hamerkop has been failing regression
tests for the last two months. The symptoms appear consistent with the
theory that the src/test/regress/data/tenk.data test file has been
converted to have DOS style line endings (\r\n). The test cases that
are failing involv
On Thu, Sep 13, 2012 at 12:14:41PM -0700, daniela florescu wrote:
> Dear all,
>
> we talked a while ago about a possible integration between Zorba
> (http://www.zorba-xquery.com/html/index), the Apache open source XML (XQuery)
> and JSON query
> (jsoniq.org) processor into Postgress.
>
> I think
Heikki Linnakangas wrote:
I don't think we can realistically support VS2012 until Microsoft
releases the gratis Visual Studio Express 2012 for Windows Desktop.
As they've released now I've updated my Patch with docs and ask for review.
Regards,
Brar
diff -Napcdr -x .git postgres/doc/src/sgml/
Kyotaro HORIGUCHI writes:
> This patch reduces run time of such queries by 45% when result
> recored has 30 columns and seems to have no harm for performance.
This patch seems quite unsafe to me: it's not generally okay for
a plan node to return a slot that doesn't belong to it, because of
tuple-
Tom Lane wrote:
> "Kevin Grittner" writes:
>> At any rate, I think we might want to apply Tom's patch for this
>> while 9.3 is still early in development, to see what else might
>> shake out from it while there is still plenty of time to fix any
>> issues. It's now looking good from my perspecti
Dear all,
we talked a while ago about a possible integration between Zorba
(http://www.zorba-xquery.com/html/index), the Apache open source XML (XQuery)
and JSON query
(jsoniq.org) processor into Postgress.
I think this would add a lot of functionality to Postgres, and the Zorba query
processor
"Kevin Grittner" writes:
> At any rate, I think we might want to apply Tom's patch for this
> while 9.3 is still early in development, to see what else might
> shake out from it while there is still plenty of time to fix any
> issues. It's now looking good from my perspective.
I just re-read the
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>>> The following bug has been logged on the website:
>>>
>>> Bug reference: 7534
>>> Logged by: Amit Kapila
>>> Email address:
On 09/13/2012 01:20 PM, Dimitri Fontaine wrote:
Tom Lane writes:
I think it would be a lot better if this were designed so that the
processor programs executed on client side. Which would probably make
it not a COPY patch at all, but something in psql.
And pgloader, which already has a part
Tom Lane writes:
> I think it would be a lot better if this were designed so that the
> processor programs executed on client side. Which would probably make
> it not a COPY patch at all, but something in psql.
And pgloader, which already has a part of that feature with the per
column reformatin
On Thu, Sep 13, 2012 at 02:29:08PM +0100, Simon Riggs wrote:
> I think we need an in-between status of
> might-work-will-remove-if-it-doesnt. The key is not whether to remove
> it, the key is whether the lack of support for certain features in an
> old OS is sufficient to prevent forward progress o
"Albe Laurenz" writes:
> Tom Lane wrote:
>> Instead, the planner arranges for the TID to be carried up as an
>> explicit resjunk column named ctid. (Currently this is done in
>> rewriteTargetListUD(), but see also preptlist.c which does some
>> related things for SELECT FOR UPDATE.)
>>
>> I'm in
"Etsuro Fujita" writes:
> I'd like to add the following options to the SQL COPY command and the psql
> \copy
> instruction:
> * PREPROCESSOR: Specifies the user-supplied program for COPY IN. The data
> from an input file is preprocessed by the program before the data is loaded
> into
> a p
2012/9/13 Albe Laurenz :
> Tom Lane wrote:
>> Kohei KaiGai writes:
>>> Laurenz Albe wrote:
Would it be too invasive to introduce a new pointer in
> TupleTableSlot
that is NULL for anything but virtual tuples from foreign tables?
>
>>> I'm not certain whether the duration of TupleTableSlo
Tom Lane wrote:
> Kohei KaiGai writes:
>> Laurenz Albe wrote:
>>> Would it be too invasive to introduce a new pointer in
TupleTableSlot
>>> that is NULL for anything but virtual tuples from foreign tables?
>> I'm not certain whether the duration of TupleTableSlot is enough to
>> carry a private d
On 13 September 2012 14:18, Noah Misch wrote:
> On Thu, Sep 13, 2012 at 10:00:51AM +0100, Simon Riggs wrote:
>> SGI support for IRIX ends in Dec 2013, following on from
>> discontinuation of hardware in 2006/7
>> http://www.sgi.com/services/support/irix_mips_support.html
>>
>> Which means 9.3 will
2012/9/13 Alvaro Herrera :
> Excerpts from Etsuro Fujita's message of jue sep 13 06:13:26 -0300 2012:
>> I'd like to add the following options to the SQL COPY command and the psql
>> \copy
>> instruction:
>>
>> * PREPROCESSOR: Specifies the user-supplied program for COPY IN. The
>> data
>> f
Excerpts from Etsuro Fujita's message of jue sep 13 06:13:26 -0300 2012:
> I'd like to add the following options to the SQL COPY command and the psql
> \copy
> instruction:
>
> * PREPROCESSOR: Specifies the user-supplied program for COPY IN. The data
> from an input file is preprocessed by t
On Thu, Sep 13, 2012 at 10:00:51AM +0100, Simon Riggs wrote:
> SGI support for IRIX ends in Dec 2013, following on from
> discontinuation of hardware in 2006/7
> http://www.sgi.com/services/support/irix_mips_support.html
>
> Which means 9.3 will not have an IRIX platform to run on for more than
>
On Wed, Sep 12, 2012 at 03:20:24PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I was surprised to find that psql -f file.sql with a file such as this
> > select 1;
> > select 2
>
> > executes both commands even though the second one is not terminated.
> I'm a little dubious about chang
Kaigai-san,
(2012/09/13 16:56), Kohei KaiGai wrote:
> What about your plan to upstream contrib/pgsql_fdw module on the upcoming
> commit-fest?
I will post pgsql_fdw patch (though it will be renamed to
postgresql_fdw) in opening CF (2012 Sep), as soon as I resolve a bug in
ANALYZE support, maybe o
I'd like to add the following options to the SQL COPY command and the psql \copy
instruction:
* PREPROCESSOR: Specifies the user-supplied program for COPY IN. The data
from an input file is preprocessed by the program before the data is loaded into
a postgres table.
* POSTPROCESSOR: Speci
On 6 May 2012 15:23, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 6 May 2012 01:06, Robert Haas wrote:
>>> I think we should err on the side of removing less rather than more.
>>> It won't hurt anything much to leave these around for another few
>>> years.
>
>> I think it's better to force us
Hello.
A very simple query shown below on partitioned tables can run for
four times as long as that on non-partitioned tables when the
whole data can be loaded onto memory.
* QUERY : SELECT * FROM t;
* EXEC TREE : Result(Append(SeqScan)) for partitioned
: SeqScan f
Hanada-san,
What about your plan to upstream contrib/pgsql_fdw module on the upcoming
commit-fest?
Even though I understand the point I noticed (miss-synchronization of sub-
transaction block between local and remote side) is never easy problem to
solve, it is worth to get the patch on the table o
On Thu, Sep 13, 2012 at 5:22 AM, Peter Eisentraut wrote:
> On Wed, 2012-09-12 at 19:13 +0200, Magnus Hagander wrote:
>> Just to be clear, what you're saying is we want to change the policy
>> that says "committer must be on list of approved committers &&
>> commiter==author" to "committer must be
27 matches
Mail list logo
