On Sat, Mar 17, 2012 at 8:48 PM, HuangQi wrote:
> About the second topic, so currently TABLESAMPLE is not implemented
> inside Postgres? I didn't see this query before, but I googled it just now
> and the query seems very weird and
> interesting. http://www.fotia.co.uk/fotia/DY.18.TheTableSamp
On Sun, Mar 18, 2012 at 01:28, Daniel Farina wrote:
> Noah offered me these comments:
>> This patch still changes the policy for pg_terminate_backend(), and it does
>> not fix other SIGINT senders like processCancelRequest() and ProcSleep(). If
>> you're concerned about PID-reuse races, audit all
> Would be nice to sort out the features of the two Postgres extentions
> pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what
> do they have in common, what is complementary?
pg_prewarm use postgresql functions (buffer manager) to warm data (different
kind of 'warm', see pg_prew
Greg Stark writes:
> I'm still curious how it would compare to call strxfrm and sort the
> resulting binary blobs.
In principle that should be a win; it's hard to believe that strxfrm
would have gotten into the standards if it were not a win for sorting
applications.
> I don't think the sortsupp
When building a minimal PostgreSQL under the latest mingw (2018),
make check will give a few dozen fails with the server exiting on code
2. The build is fine when -O2 is removed from the CFLAGS. This behaviour
is present on all revs on the REL9_1_STABLE branch that I tested, among
which wer
Jeff Janes writes:
> On Wed, Mar 7, 2012 at 11:55 AM, Robert Haas wrote:
>> On Sat, Mar 3, 2012 at 4:15 PM, Jeff Janes wrote:
>>> Anyway, I think the logtape could use redoing.
> The problem there is that none of the files can be deleted until it
> was entirely read, so you end up with all the
On 2012-03-18 15:25, Tom Lane wrote:
Jeff Janes writes:
On Wed, Mar 7, 2012 at 11:55 AM, Robert Haas wrote:
The problem there is that none of the files can be deleted until it
was entirely read, so you end up with all the data on disk twice. I
don't know how often people run their databases s
On 03/18/2012 11:12 AM, Yeb Havinga wrote:
When building a minimal PostgreSQL under the latest mingw (2018),
make check will give a few dozen fails with the server exiting on code
2. The build is fine when -O2 is removed from the CFLAGS. This
behaviour is present on all revs on the REL9_1
Jeremy Harris writes:
> On 2012-03-18 15:25, Tom Lane wrote:
>> Yeah, that was me, and it came out of actual user complaints ten or more
>> years back. (It's actually not 2X growth but more like 4X growth
>> according to the comments in logtape.c, though I no longer remember the
>> exact reasons
On Sun, Mar 18, 2012 at 3:25 PM, Tom Lane wrote:
>>> No, it's about reducing the number of comparisons needed to maintain
>>> the heap property.
>
>> That sounds very interesting. I didn't know it was even theoretically
>> possible to do that.
>
> So has somebody found a hole in the n log n lower
Peter Geoghegan writes:
> Is there anything that I could be doing to help bring this patch
> closer to a committable state?
Sorry, I've not actually looked at that patch yet. I felt I should
push on Andres' CTAS patch first, since that's blocking progress on
the command triggers patch.
> I'm th
On Sun, Mar 18, 2012 at 8:56 AM, Greg Stark wrote:
> On Sun, Mar 18, 2012 at 3:25 PM, Tom Lane wrote:
No, it's about reducing the number of comparisons needed to maintain
the heap property.
>>
>>> That sounds very interesting. I didn't know it was even theoretically
>>> possible to do
On Sat, Mar 17, 2012 at 05:28:11PM -0700, Daniel Farina wrote:
> Noah offered me these comments:
> > This patch still changes the policy for pg_terminate_backend(), and it does
> > not fix other SIGINT senders like processCancelRequest() and ProcSleep().
> > ?If
> > you're concerned about PID-reus
BTW, I've been looking through how to do what I suggested earlier to get
rid of the coziness and code duplication between CreateTableAs and the
prepare.c code; namely, let CreateTableAs create a DestReceiver and then
call ExecuteQuery with that receiver. It appears that we still need at
least two
Tom Lane writes:
> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
> that it can enforce that the prepared query is a SELECT. (BTW, maybe
> this should be weakened to "something that returns tuples", in view of
> RETURNING?)
That lights a bulb: what about rewriting CREATE
On lör, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
> I'm not sure what we should do instead. We have gotten push-back before
> anytime we changed the command tag for an existing command (and in fact
> it seems that we intentionally added the rowcount display in 9.0, which
> means there are people
On 18 March 2012 16:13, Tom Lane wrote:
> Is there a really strong reason why adequate regression testing isn't
> possible in a plain-vanilla pg_regress script? A quick look at the
> script says that it's just doing some SQL commands and then checking the
> results of queries on the pg_stat_state
On 03/18/2012 06:12 PM, Peter Geoghegan wrote:
On 18 March 2012 16:13, Tom Lane wrote:
Is there a really strong reason why adequate regression testing isn't
possible in a plain-vanilla pg_regress script? A quick look at the
script says that it's just doing some SQL commands and then checking
On 18 March 2012 22:46, Andrew Dunstan wrote:
> If you want to generate the tests using some tool, then use whatever works
> for you, be it Python or Perl or Valgol, but ideally what is committed (and
> this what should be in your patch) will be the SQL output of that, not the
> generator plus inp
On 03/18/2012 07:46 PM, Peter Geoghegan wrote:
On 18 March 2012 22:46, Andrew Dunstan wrote:
If you want to generate the tests using some tool, then use whatever works
for you, be it Python or Perl or Valgol, but ideally what is committed (and
this what should be in your patch) will be the SQ
On 19 March 2012 00:10, Andrew Dunstan wrote:
> If your tests are that voluminous then maybe they are not what we're looking
> for anyway. As Tom noted:
>
>
> IMO the objective of a regression test is not to memorialize every single
> case the code author thought about during development. ISTM
Dimitri Fontaine writes:
> That lights a bulb: what about rewriting CREATE TABLE AS as two
> commands, internally:
Given the compatibility constraints on issues like what command tag
to return, I think that would probably make our jobs harder not easier.
regards, tom lane
Peter Eisentraut writes:
> On lör, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
>> I'm not sure what we should do instead. We have gotten push-back before
>> anytime we changed the command tag for an existing command (and in fact
>> it seems that we intentionally added the rowcount display in 9.0,
Peter Geoghegan writes:
> On 19 March 2012 00:10, Andrew Dunstan wrote:
>> Why exactly does this feature need particularly to have script-driven
>> regression test generation when others don't?
> It's not that it needs it, so much as that it is possible to provide
> coverage for much of the code
On 19 March 2012 01:50, Tom Lane wrote:
> I am *not* a fan of regression tests that try to microscopically test
> every feature in the system.
I see your point of view. I suppose I can privately hold onto the test
suite, since it might prove useful again.
I will work on a pg_regress based approa
The implementation seems to be done quite fully. There is even a patch
file. Why is the implementation not added into the release of Postgres? As
so much has already being done, what could I do in this case for the Gsoc?
On Sun, Mar 18, 2012 at 6:38 PM, Daniel Farina wrote:
> On Sat, Mar 17, 201
On Fri, Mar 16, 2012 at 10:17 PM, Tom Lane wrote:
> Shigeru HANADA writes:
>> During writing pgsql_fdw codes, I noticed that exprCollation rejects
>> non-Expr nodes with error "unrecognized node type: %d". Is this
>> intentional behavior, or can it return InvalidOid for unrecognized nodes
>> lik
(2012/03/16 22:51), Shigeru Hanada wrote:
2012/3/16 Etsuro Fujita:
The index creation is supported for a flat file such as CSV and a remote
table on a RDB e.g., Postgres using CREATE INDEX.
IMHO CREATE INDEX for foreign tables should have general design,
not specific to some kind of FDWs.
(2012/03/17 2:07), David Fetter wrote:
On Fri, Mar 16, 2012 at 11:58:29AM +0200, Heikki Linnakangas wrote:
On 16.03.2012 10:44, Etsuro Fujita wrote:
For a flat file, CREATE INDEX constructs
an index in the same way as an index for a regular table.
For starters, how would you keep the index
29 matches
Mail list logo
