On Nov 24, 2007 12:39 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Surely such applications would be using prepare queries though?
Surely the good ones. I know you can only save people from themselves
to a certain point... I just didn't want to dismiss it completely.
--
Jonah H. Harris, Sr. S
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Nov 23, 2007 8:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So I'm satisfied with these results, particularly in view of the
>> fact that what we're measuring is certainly the stupidest, least
>> efficient way to use Postgres.
>
> Given the emerg
On Nov 24, 2007 12:04 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I didn't intend to say that select-only transactions aren't interesting;
> rather that there should be some minimal effort on the application side.
> The cases we are testing here involve:
Agreed, thanks for clarifying.
--
Jonah H.
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Nov 23, 2007 8:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So I'm satisfied with these results, particularly in view of the
>> fact that what we're measuring is certainly the stupidest, least
>> efficient way to use Postgres.
> Given the emergin
On Nov 23, 2007 8:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So I'm satisfied with these results, particularly in view of the
> fact that what we're measuring is certainly the stupidest, least
> efficient way to use Postgres.
Given the emerging world of data-driven content management systems and
I wrote:
> I don't think you need to --- the "read-only transaction" case built
> into pgbench is probably an equivalent test. What it looks like to
> me is that the EquivalenceClass mechanism has added a little bit of
> overhead, which isn't actually buying much of anything in these
> trivial cas
>>> On Fri, Nov 23, 2007 at 5:31 AM, in message <[EMAIL PROTECTED]>,
Dragan Zubac <[EMAIL PROTECTED]> wrote:
>
> Didn't know where to submit question regarding design&performance.
This page is the place to figure that out:
http://www.postgresql.org/community/lists/
For the questions you h
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I noticed that tapir is failing the plpython PLCheck test in the 8.1
> branch. I was worried for a jiffy that it could be related to my
> changes of yesterday, but on looking closer it seems it has been failing
> for quite a while ..
> Hmm, oh, and in
I noticed that tapir is failing the plpython PLCheck test in the 8.1
branch. I was worried for a jiffy that it could be related to my
changes of yesterday, but on looking closer it seems it has been failing
for quite a while ..
Hmm, oh, and in looking even closer, the reason it's not failing in 8
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> Markus Schiltknecht wrote:
>>> And why do you need lots of heap memory to do that? Anything wrong with the
>>> zipper approach I've outlined upthread?
>>
>> We're talking about a binary heap, with just
Thomas =?iso-8859-1?q?G=FCttler?= <[EMAIL PROTECTED]> writes:
> I get the following compile warnings:
> like.c:137: warning: inlining failed in call to `Generic_Text_IC_like'
> Should this reported to the bug tracker?
No, because we aren't going to do anything about those. They're purely
inform
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> No, it isn't. Please add a TODO item about it:
> * Prevent long-lived temp tables from causing frozen-Xid advancement
> starvation
> >>
> > Jeff Amiel wrote:
> >> Can somebody explain this one to me? because of our aud
Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > I am confused. You stated in your earlier email:
> >
> >> Looking again at bug report [1], I agree that's a glibc bug. Numbers
> >> in pt_BR has its format 1.234.567,89; sometimes the format 1234567,89
> >> is acceptable too, ie, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory Stark wrote:
> But that requires a) dealing with the problem of the parent table which has no
> constraints and b) an efficient way to prove that constraints don't overlap
> and order them properly. The latter looks like an O(n^2) problem to me
> > But that requires a) dealing with the problem of the parent table
which has no
> > constraints and ...
Imho we should provide a mechanism that forces the parent to be empty
and let the planner know.
e.g. a false constraint on parent ONLY.
Andreas
---(end of broadcas
Gregory Stark wrote:
Ideally we would also be able to do this in the planner. If the planner could
determine from the constraints that all the key values from each partition are
non-overlapping and order them properly then it could generate a regular
append node with a path order without the over
Gregory Stark wrote:
Not quite the same since the Executor-based implementation would have a static
tree structure based on the partitions. Even if the partitions are all empty
except for one or two you would still have to push the result records through
all the nodes for the empty partitions.
A
On Fri, 2007-11-23 at 12:36 +, Gregory Stark wrote:
> I also did an optimization similar to the bounded-sort case where we check if
> the next tuple from the same input which last contributed the result record
> comes before the top element of the heap. That avoids having to do an insert
> and
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Markus Schiltknecht wrote:
>> Florian Weimer wrote:
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use case you
Tt seems that GCC makes decision do not inline this function and then it
will keep as a standard function. It is not problem and this warning is
generated by -Winline. I don't have this problem with GCC 3.4.3
Zdenek
Thomas Güttler wrote:
Hi,
I get the following compile warnings:
gc
Hello all
Didn't know where to submit question regarding design&performance.
Here's the situation.
Basically process will take one message at a time,send it and the will
send another one,each process knows which message to take from the table
based on provider value.
First situation:
table
Euler Taveira de Oliveira wrote:
> Bruce Momjian wrote:
>
> > OK, I researched this and realized it should have been obvious to me
> > when I added this code in 2006 that making the thousands separator
> > always "," for a locale of "" was going to cause a problem.
> >
> I tested your patch and I
On Thu, 2007-11-22 at 22:29 +, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >
> > I'm thinking of some performance regression testing to see what else is
> > lurking around the corner for us.
>
> If you have something you can just throw over the fence, I can run stuff
> on Imola as well.
On Fri, 2007-11-23 at 01:14 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > That's a killer reason, I suppose. I was really trying to uncover what
> > the thinking was, so we can document it. Having VACUUM ignore it
> > completely seems wrong.
>
> What you seem to be forgettin
Hi,
Heikki Linnakangas wrote:
AFAICT it's roughly the same data structure as the zipper tree you
envisioned, but not implemented with separate executor nodes for each
level.
Aha, that sounds good to me. ;-)
As I've already mentioned, I think it's even better to simply show the
user a single
* Markus Schiltknecht:
>> You need a priority queue to figure out from which tape (partition)
>> you need to remove the next tuple.
>
> And why do you need lots of heap memory to do that? Anything wrong
> with the zipper approach I've outlined upthread?
"heap" == "priority queue" here, I guess.
Markus Schiltknecht wrote:
Florian Weimer wrote:
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use case you have in mind?
You need a priority queue to figure out from which tape
Hi,
Florian Weimer wrote:
Florian Weimer wrote:
I think you need it because there are potentially many input types.
Eh, "tapes".
Aha..
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate
* Markus Schiltknecht:
> Florian Weimer wrote:
>> I think you need it because there are potentially many input types.
Eh, "tapes".
> Given the partitioning case, I'd expect all rows to have an equal
> tuple descriptor. Maybe this is a matter of what to optimize, then?
>
> Could you elaborate on
Hi,
Florian Weimer wrote:
I think you need it because there are potentially many input types.
Given the partitioning case, I'd expect all rows to have an equal tuple
descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use case you have in mind?
Regards
* Markus Schiltknecht:
>> uses a heap to efficiently find the next value from the source tapes.
>
> Well, maybe my point here is: why do you need the heap to sort?
I think you need it because there are potentially many input types.
--
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-co
Hi,
I get the following compile warnings:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels
-fno-strict-aliasing -I../../../../src/include -D_GNU_SOURCE -c -o like.o
like.c
like.c: In function `texticnlike':
like.c:137: warning: inlining failed in call to `Generic_Tex
Hello Gregory,
Gregory Stark wrote:
It is kind of like a merge join but not quite. It's interleaving rows rather
than matching them up. It's more like the final merge of a sort which also
uses a heap to efficiently find the next value from the source tapes.
Well, maybe my point here is: why do
33 matches
Mail list logo
