On Fri, Oct 29, 2010 at 3:23 PM, Heikki Linnakangas
wrote:
> Simon's argument in the thread that the todo item points to
> (http://archives.postgresql.org/pgsql-patches/2008-07/msg00123.php) is
> basically that we don't know what the best algorithm is yet and benchmarking
> is a lot of work, so le
On 29.10.2010 06:00, Jeff Janes wrote:
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
I wrote:
> the right way to make this faster is to refactor things so that we
> don't generate useless equivalence classes in the first place, or
> at least don't keep them around in the planner's lists once we realize
> they're useless.
After a bit of hacking, I propose the attached patch.
> I l
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> optio
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 t
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 on
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
> 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 anoth
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
from
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
Sorr
> 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 18 October 2010 01:19, Tom Lane wrote:
> Brendan Jurd writes:
>> On 17 October 2010 09:59, Tom Lane 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 after the
>>> initial lexing. I still think
Boszormenyi Zoltan 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 issue is i
Ben 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 the cutover
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.
> >>
> >
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 a
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
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 if
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. Pas
Ben 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? is the const
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?
Be
Tom Lane írta:
> Boszormenyi Zoltan 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
>
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 otherwise
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 Thu, Oct 28, 2010 at 11:34 AM, Tom Lane wrote:
> Andrew Dunstan 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 functio
On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane wrote:
> Pavel Stehule 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 o
2010/10/28 Andrew Dunstan :
>
>
> 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
Andrew Dunstan 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 .. some li
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 woul
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 th
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, th
Alvaro Herrera 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 it's used inside critica
2010/10/28 Tom Lane :
> Andrew Dunstan 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
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 rep
2010/10/28 Andrew Dunstan :
> 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
Andrew Dunstan 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 arguments, so tha
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, we'
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
The P
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:
http://www.postgresql.o
On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus 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 better.
[moving to -hackers, from -performance]
On Wed, Oct 27, 2010 at 11:32 PM, Tom Lane wrote:
> Robert Haas 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 ... do we need a commit at all in
Pavel Stehule 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 there is
supposed to be
Heikki Linnakangas 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 of the main canon_pathkeys list l
Boszormenyi Zoltan 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 last call lis
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 ret
"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
>> b
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
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, h
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
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
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 pat
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 woul
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
>>
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
54 matches
Mail list logo
