Heikki Linnakangas írta:
On 26.10.2010 18:34, Boszormenyi Zoltan wrote:
thank you very much for pointing me to dynahash, here is the
next version that finally seems to work.
Two patches are attached, the first is the absolute minimum for
making it work, this still has the Tree type for
Boszormenyi Zoltan írta:
Heikki Linnakangas írta:
On 26.10.2010 18:34, Boszormenyi Zoltan wrote:
thank you very much for pointing me to dynahash, here is the
next version that finally seems to work.
Two patches are attached, the first is the absolute minimum for
making it work,
This is not very user-friendly:
postgres=# do $$
begin
COMMIT;
end;
$$;
ERROR: SPI_execute_plan_with_paramlist failed executing query COMMIT:
SPI_ERROR_TRANSACTION
CONTEXT: PL/pgSQL function inline_code_block line 2 at SQL statement
Clearly we don't support that, but seems like it would
Boszormenyi Zoltan írta:
Boszormenyi Zoltan írta:
Heikki Linnakangas írta:
On 26.10.2010 18:34, Boszormenyi Zoltan wrote:
thank you very much for pointing me to dynahash, here is the
next version that finally seems to work.
Two patches are attached, the first is
Hello, Andrew.
You wrote:
AD It occurred to me in the dead of the night that instead of:
AD ALTER TYPE enumtype ADD 'newlabel'
AD it might be better to have:
AD ALTER TYPE enumtype ADD LABEL 'newlabel'
AD That way if we later wanted to support some other sort of ADD operation
AD
Hello, Andrew.
You wrote:
AD It occurred to me in the dead of the night that instead of:
AD ALTER TYPE enumtype ADD 'newlabel'
AD it might be better to have:
AD ALTER TYPE enumtype ADD LABEL 'newlabel'
AD That way if we later wanted to support some other sort of ADD operation
AD
Boszormenyi Zoltan írta:
Boszormenyi Zoltan írta:
Boszormenyi Zoltan írta:
Heikki Linnakangas írta:
On 26.10.2010 18:34, Boszormenyi Zoltan wrote:
thank you very much for pointing me to dynahash, here is the
next version that finally
On 28.10.2010 13:54, Boszormenyi Zoltan wrote:
A little better version, no need for the heavy hash_any, hash_uint32
on the lower 32 bits on pk_eclass is enough. The profiling runtime
is now 0.42 seconds vs the previous 0.41 seconds for the tree version.
Actually, I wonder if we could just have
Joshua D. Drake wrote:
On Wed, 2010-10-27 at 19:52 -0400, Robert Haas wrote:
Josh Berkus wrote:
*you don't know* how many .org users plan to implement
replication, whether it's a minority or majority.
None of us know. What I do know is that I don't want PostgreSQL to
be slower out of
Hello
I am checking PLpgSQL ToDo topics, and I am not sure if this topic
isn't done. And if not, then I would to get some detail.
Now there is possible to test row's variable on NULL, now it is
possible to assign NULL to row variable. What we can do more?
a) There is small difference between
Boszormenyi Zoltan z...@cybertec.at writes:
This means add_child_rel_equivalences() is still takes
too much time, the previously posted test case calls this
function 482 times, it's called for almost every 10th entry
added to eq_classes. The elog() I put into this function says
that at the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Actually, I wonder if we could just have a separate canon_pathkeys list
for each EquivalenceClass, instead of one big list in PlannerInfo. I'm
not too familiar with equivalence classes and all that,
Hm. I don't like getting rid
Pavel Stehule pavel.steh...@gmail.com writes:
I am checking PLpgSQL ToDo topics, and I am not sure if this topic
isn't done. And if not, then I would to get some detail.
I think that thread petered out because we didn't have consensus on
what the behavior ought to be. It goes back to whether
[moving to -hackers, from -performance]
On Wed, Oct 27, 2010 at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Gee, I wonder if it would possible for PG to automatically do an
asynchronous commit of any transaction which touches only temp tables.
Hmm
On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus j...@agliodbs.com wrote:
I sort of agree with you that the current checkpoint_segments
parameter is a bit hard to tune, at least if your goal is to control
the amount of disk space that will be used by WAL files. But I'm not
sure your proposal is
I have committed an initial version of release notes for 9.1alpha2.
Please look it over.
The release can then be prepared over the weekend and announced on
Monday.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
Hah, there are 17 votes as of right now, no option is below 23% and no
option is above 29%.
--
Álvaro Herrera
While we were discussing allowing generic record type arguments to
plperl functions, Tom suggested that we should expose the type
information about the record members to plperl. I think if we do that we
should probably expand it somewhat to all arguments, so that for
non-trigger functions,
Andrew Dunstan and...@dunslane.net writes:
While we were discussing allowing generic record type arguments to
plperl functions, Tom suggested that we should expose the type
information about the record members to plperl. I think if we do that we
should probably expand it somewhat to all
2010/10/28 Andrew Dunstan and...@dunslane.net:
While we were discussing allowing generic record type arguments to plperl
functions, Tom suggested that we should expose the type information about
the record members to plperl. I think if we do that we should probably
expand it somewhat to all
Excerpts from Tom Lane's message of mié oct 27 19:01:38 -0300 2010:
I don't know what Simon is thinking, but I think he's nuts. There is is
obvious extra overhead in COMMIT:
/*
* Wake up all walsenders to send WAL up to the COMMIT record
* immediately if
2010/10/28 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
While we were discussing allowing generic record type arguments to
plperl functions, Tom suggested that we should expose the type
information about the record members to plperl. I think if we do that we
Alvaro Herrera alvhe...@commandprompt.com writes:
BTW I note that there are no elog(ERROR) calls in that code path at all,
because syscall errors are ignored, so PANIC is not a concern (as the
code stands currently, at least). ISTM it would be good to have a
comment on SetLatch stating that
On 10/28/2010 11:54 AM, Pavel Stehule wrote:
Alternatively, maybe the feature could be exposed in a way where you
don't actually calculate the values unless requested, ie provide some
sort of inquiry function instead of always precomputing a hash.
+1 .. some like get_function_info()
Yeah,
On 10/28/2010 12:23 PM, David E. Wheeler wrote:
On Oct 27, 2010, at 9:08 PM, Andrew Dunstan wrote:
Well, it turns out that the hashref required exactly one more line to achieve.
We already have all the infrastructure on the composite handling code, and all
it requires it to enable it for
On Oct 27, 2010, at 9:08 PM, Andrew Dunstan wrote:
Well, it turns out that the hashref required exactly one more line to
achieve. We already have all the infrastructure on the composite handling
code, and all it requires it to enable it for the RECORDOID case.
I don't suppose that it would
Andrew Dunstan and...@dunslane.net writes:
On 10/28/2010 11:54 AM, Pavel Stehule wrote:
Alternatively, maybe the feature could be exposed in a way where you
don't actually calculate the values unless requested, ie provide some
sort of inquiry function instead of always precomputing a hash.
+1
2010/10/28 Andrew Dunstan and...@dunslane.net:
On 10/28/2010 11:54 AM, Pavel Stehule wrote:
Alternatively, maybe the feature could be exposed in a way where you
don't actually calculate the values unless requested, ie provide some
sort of inquiry function instead of always precomputing a
On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
I am checking PLpgSQL ToDo topics, and I am not sure if this topic
isn't done. And if not, then I would to get some detail.
I think that thread petered out because we didn't have
On Thu, Oct 28, 2010 at 11:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/28/2010 11:54 AM, Pavel Stehule wrote:
Alternatively, maybe the feature could be exposed in a way where you
don't actually calculate the values unless requested, ie provide
hello --
i have a largish table (~8 billion rows) which makes use of the temporal period
datatype and gist indexes. i find that query plans are somewhat unstable in
that it is often the case that slightly altering a query can result in a change
from using the index (usually via a bitmap scan)
On 10/28/2010 12:34 PM, Tom Lane wrote:
BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched. Passing the data as a hash definitely
seems to fit with the spirit of things
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
This means add_child_rel_equivalences() is still takes
too much time, the previously posted test case calls this
function 482 times, it's called for almost every 10th entry
added to eq_classes. The elog() I put into this function
On Oct 28, 2010, at 9:31 AM, Andrew Dunstan wrote:
Of course it's possible, but it's a different feature. As for just as easy,
no, it's much more work. I agree it should be done, though.
I bet we could raise some money to fund it's development. How much work are we
talking about here?
Best,
Ben midfi...@gmail.com writes:
my guess is that it has to do with the selectivity of the @ operator. i've
looked and noticed that the selectivity functions for @ and other period
operators are basically stubs, with constant selectivity. my questions are :
1 - am i wrong in my assessment?
On Thu, Oct 28, 2010 at 01:03:24PM -0400, Andrew Dunstan wrote:
On 10/28/2010 12:34 PM, Tom Lane wrote:
BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only if it's actually touched. Passing the
On 10/28/2010 02:11 PM, Garick Hamlin wrote:
On Thu, Oct 28, 2010 at 01:03:24PM -0400, Andrew Dunstan wrote:
On 10/28/2010 12:34 PM, Tom Lane wrote:
BTW, maybe we could have the best of both worlds? Dunno about Perl,
but in some languages it would be possible to instantiate the hash
only
thanks for the prompt reply.
On Oct 28, 2010, at 10:50 AM, Tom Lane wrote:
1 - am i wrong in my assessment? is the constant contsel, areasel, etc
hurting us?
The stub selectivity functions definitely suck.
i'm taking this as implying that my intuition here is basically right.
2 - how
On ons, 2010-10-20 at 22:56 -0400, Josh Kupershmidt wrote:
It looks like psql's tab completion for the \z and \dg commands in
psql are missing. I couldn't see a reason for this, so attached patch
fixes.
Also, this patch proposes to change psql's \? help text to say that
\dg and \du are the
On Thu, 2010-10-28 at 07:05 -0500, Kevin Grittner wrote:
Joshua D. Drake wrote:
On Wed, 2010-10-27 at 19:52 -0400, Robert Haas wrote:
Josh Berkus wrote:
*you don't know* how many .org users plan to implement
replication, whether it's a minority or majority.
None of us know. What
Ben midfi...@gmail.com writes:
On Oct 28, 2010, at 10:50 AM, Tom Lane wrote:
However, having said that: the constant value of the stub contsel
function is intended to be small enough to encourage use of an
indexscan. Maybe we just need to decrease it a bit more. Have you
investigated what
Boszormenyi Zoltan z...@cybertec.at writes:
Tom Lane írta:
That seems like a ridiculously large number of ECs. What is the
test query again?
The test case is here:
http://archives.postgresql.org/message-id/4cbd9ddc.4040...@cybertec.at
After poking through that a bit, I think that the real
On 18 October 2010 01:19, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
On 17 October 2010 09:59, Tom Lane t...@sss.pgh.pa.us wrote:
Good point. Maybe the correct fix is to remember whether each token was
quoted or not, so that keyword detection can be done safely
https://www.postgresqlconference.org/content/replication-poll
You don't have to login to take it but of course it helps with validity
of results.
Oh, I'd already put something up on http://www.postgresql.org/community
--
-- Josh Berkus
On Thu, 2010-10-28 at 16:25 -0700, Josh Berkus wrote:
https://www.postgresqlconference.org/content/replication-poll
You don't have to login to take it but of course it helps with validity
of results.
Oh, I'd already put something up on http://www.postgresql.org/community
Sorry, didn't
The buildfarm server is moving. The web site has already moved, and the
database will be moving on Tuesday Nov 9th, starting at 9.00 am EST (or,
if you prefer, at 14:00 UTC). The server will be unavailable during the
outage, which is expected to take no longer then 6 hours. (we're moving
Sorry, didn't know... I have 122 responses so far, which I think will be
surprising (some of them certainly surprised me). I will keep it open
until next week and then post the results.
Well, for any community site poll, I hope you realize that there's a LOT
of sampling error. Here's another
On Thu, 2010-10-28 at 17:12 -0700, Josh Berkus wrote:
Sorry, didn't know... I have 122 responses so far, which I think will be
surprising (some of them certainly surprised me). I will keep it open
until next week and then post the results.
Well, for any community site poll, I hope you
One of the items on the Wiki ToDo list is sorted writes for
checkpoints. The consensus seemed to be that this should be done by
adding hook(s) into the main code, and then a contrib module to work
with those hooks. Is there an existing contrib module that one could
best look to for inspiration
Excerpts from Jeff Janes's message of vie oct 29 00:00:24 -0300 2010:
One of the items on the Wiki ToDo list is sorted writes for
checkpoints. The consensus seemed to be that this should be done by
adding hook(s) into the main code, and then a contrib module to work
with those hooks. Is
Hello, Alvaro.
You wrote:
AH Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
AH Hah, there are 17 votes as of right now, no option is below 23% and no
AH option is
51 matches
Mail list logo
