Bruce Momjian wrote:
Sushant Sinha wrote:
The default headline generation function is complicated. It checks a lot
of cases to determine the best headline to be displayed. So Heikki's
examples just say that headline generation function may not be very
intuitive. However, his examples were not af
Jaime Casanova wrote:
On Wed, Jan 7, 2009 at 1:46 AM, KaiGai Kohei wrote:
The attached patch is a proof of the concept.
It walks on a given query tree to append accessed columns on
rte->cols_sel and rte->cols_mod.
When aliasvar of JOIN'ed relation is accesses, its source is
appended on the list
On Thu, Jan 8, 2009 at 2:20 PM, Bruce Momjian wrote:
> OK, what is the TODO? It is more than AM/PM, right?
>
I see it happening in two stages.
Stage 1 is updating the AM/PM parse code to use the seq_search
technique, which may involve some minor refactoring around seq_search
itself. This will
On Wed, Jan 7, 2009 at 1:46 AM, KaiGai Kohei wrote:
>
> The attached patch is a proof of the concept.
> It walks on a given query tree to append accessed columns on
> rte->cols_sel and rte->cols_mod.
> When aliasvar of JOIN'ed relation is accesses, its source is
> appended on the list.
>
for my t
On Wed, Jan 7, 2009 at 5:46 PM, Tom Lane wrote:
> Bruce Momjian writes:
>>> * Simon Riggs (si...@2ndquadrant.com) wrote:
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion?
>
>> This new change also adds the con
Is this a TODO?
---
Tom Lane wrote:
> [ back to the when-to-inline-WITHs discussion ]
>
> Gregory Stark writes:
> >> Tom Lane wrote:
> >>> Any thoughts on what to do? One possibility is to flatten only
> >>> if the subque
Bruce Momjian writes:
> I assume this is a TODO, right?
Yah.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian writes:
> Is this a TODO?
I'm inclined to leave it as-is, at least till we get some field
feedback about how people want it to behave.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
> Has this been completed? TODO item?
> > > I'd be more inclined to deal with the issue by trying to establish
a
> > > "safety margin" in the estimate of whether the hash will go
> > multi-batch.
> > > IOW we should disuse_physical_tlist if the hash is estimated to be
> > close to but still withi
"Jaime Casanova" writes:
> what i still doesn't understand is why we need a third value at all?
There are cases for wanting all three.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
Brendan Jurd wrote:
> On Sat, Sep 27, 2008 at 4:08 AM, Tom Lane wrote:
> > "Alex Hunsaker" writes:
> >> However that still leaves the original complaint around (at least IMHO):
> >
> >> select to_timestamp('AN', 'AM');
> >> ERROR: invalid AM/PM string
> >
> >> select to_timestamp('11:47 PM 27 Se
On Thu, Jan 8, 2009 at 2:10 PM, Bruce Momjian wrote:
> Brendan, did you ever complete this patch?
>
I didn't, no. I still intend on doing work in this area, but
obviously it will have to be in the 8.5 cycle.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Brendan Jurd wrote:
> On Thu, Jan 8, 2009 at 2:10 PM, Bruce Momjian wrote:
> > Brendan, did you ever complete this patch?
> >
>
> I didn't, no. I still intend on doing work in this area, but
> obviously it will have to be in the 8.5 cycle.
OK, what is the TODO? It is more than AM/PM, right?
-
I assume this is a TODO, right?
---
Tom Lane wrote:
> I looked a bit at the bug report here:
> http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php
>
> ISTM that the fundamental problem is that plpgsql doesn't dis
Is this a TODO?
---
Bjorn Munch wrote:
> On 02/10 17.29, Peter Eisentraut wrote:
> > Tom Lane wrote:
> > >>I think the right fix would be to convert those .sql files to
> > >>input/*.source files and have pg_regress substit
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Could you deliver "bool validate" to the validate_string_relopt callback?
In this specification, invoked callback cannot know whether it should
really raise an error for invalid reloption, or not.
Hmm, would it be better to not call the validation cal
Magnus Hagander wrote:
> ITAGAKI Takahiro wrote:
> > Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
> > (at least encoding) on Windows.
> >
> Hmm. Is this actually cleaner than using the original method as
> suggested? Because if I understand things right, that version d
Sushant Sinha wrote:
> The default headline generation function is complicated. It checks a lot
> of cases to determine the best headline to be displayed. So Heikki's
> examples just say that headline generation function may not be very
> intuitive. However, his examples were not affected by the bu
The default headline generation function is complicated. It checks a lot
of cases to determine the best headline to be displayed. So Heikki's
examples just say that headline generation function may not be very
intuitive. However, his examples were not affected by the bug.
Because of the bug, hlcov
KaiGai Kohei wrote:
> Could you deliver "bool validate" to the validate_string_relopt callback?
> In this specification, invoked callback cannot know whether it should
> really raise an error for invalid reloption, or not.
Hmm, would it be better to not call the validation callback at all if
vali
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> In addition, please note that expression_tree_walker() invokes
> check_stack_depth() to prevent unexpected stack overflow.
Ah, that's the part I was looking for and somehow overlooked. As long
as we're checking at some point then I worry alo
Uh, where are we on this? I see the same output in CVS HEAD as Heikki,
and I assume he thought at least one of them was wrong. ;-)
---
Heikki Linnakangas wrote:
> Sushant Sinha wrote:
> > Patch #2. I think this is a straig
Has this been completed? TODO item?
---
Lawrence, Ramon wrote:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > I was intending to do it the other way, actually. An extra field in
> > HashPath hardly costs anything. The
Alvaro Herrera wrote:
> Agreed, it seems better. The attached patch adds that, a macro you
> originally requested and another one, and it also fixes an off-by-one
> bug I discovered while testing all of this. I also attach the testing
> patch I play with to check that this all works nicely.
| **
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> Is it possible to implement a walker function to pick up appeared
>>> columns and to chain them on rte->cols_sel/cols_mod?
>>> In this idea, columns in Query->targetList should be chained on
>>> rte->cols_mod, and
Added to TODO:
Improve CLUSTER performance by sorting to reduce random I/O
* http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php
---
Gregory Stark wrote:
>
> One thing that's bee
Andrew Dunstan writes:
> Now, we could decide that we always want to do a safe truncate in a
> parallel restore (i.e. if we have created the table in the same
> restore), even if archive_mode is on. Then this switch would be
> redundant, and we might avoid some confusion. I'm inclined to do tha
Alvaro Herrera writes:
> Tom Lane wrote:
>> What you seem to be supposing is that the only possible use pattern
>> for these macros is a for-loop containing nothing but calls to one
>> or another of the macros.
> You're right. I initially wrote these macros to reduce the amount of
> code in heap
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Well, hold on a minute. I said that was an alternative to look at,
> >> not that it was necessarily better. Can you define in words of one
> >> syllable which queries will be exposed this way? I don't believe
> >> it's "all of the
Tom Lane wrote:
> Alvaro Herrera writes:
> > Oh, the patch also removes a bunch of "continue" statements that, as far
> > as I can tell, no longer work after the macros were wrapped in
> > do { ... } while (0) :-( I don't see any nice way to put the facility
> > back.
>
> Hmm ... I guess you cou
I wrote:
> The good thing about using debug_query_string is that "the current
> client query" is well-defined and easy to explain. I'm worried
> whether using ActivePortal isn't likely to result in a rather
> implementation-dependent behavior that changes from release to release.
In fact, it *is*
Tom Lane wrote:
> This is not only really ugly, but 100% toast-specific. The
> qualified-name approach ("toast.autovacuum_enabled") has at least
> a chance of being good for something else. Or just make it
> toast_autovacuum_enabled and do the translation magic at some low
> level in the stateme
Bruce Momjian writes:
> Tom Lane wrote:
>> Well, hold on a minute. I said that was an alternative to look at,
>> not that it was necessarily better. Can you define in words of one
>> syllable which queries will be exposed this way? I don't believe
>> it's "all of them".
> Well, if you call a p
Jaime Casanova wrote:
Anyway i tried to run with
--truncate-before-load and got a message about that should be
necessary to run TRUNCATE CASCADE instead.
Actually, this raises an interesting point. It doesn't seem safe to
truncate before loading unless we have just created the table ear
D'Arcy J.M. Cain wrote:
> On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
> Bruce Momjian wrote:
> > D'Arcy J.M. Cain wrote:
> > > So what have we decided about this suggestion. Should I submit the
> > > patch or just forget about it? So far some people like it and some
> > > people think that it is unn
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> The alternative I was envisioning was to have it look at the
> >> ActivePortal's query string. However, if you prefer to define the
> >> function as returning the current client query, it's fine as-is.
> >> We should make sure the d
On Wed, 2009-01-07 at 17:46 -0500, Tom Lane wrote:
> Bruce Momjian writes:
> >> * Simon Riggs (si...@2ndquadrant.com) wrote:
> >>> I don't really understand this. Who can set up an inherited table
> >>> structure but can't remember to turn on constraint_exclusion?
>
> > This new change also adds
"D'Arcy J.M. Cain" writes:
> Bruce Momjian wrote:
>> As I remember, no actual patch was posted for this.
> There was. I am attaching it again in case there were any changes to
> original files in the meantime.
I think what Bruce meant to say is that this patch doesn't produce 100%
spec-complia
Tom Lane wrote:
> Alvaro Herrera writes:
> > Bruce Momjian wrote:
> >> The script certainly has no way to know it is missing an extern, and I
> >> am not sure how I would even teach it that trick.
>
> > It would be easy if the compiler were to have an option to throw a
> > warning when it finds a
Bruce Momjian writes:
> Tom Lane wrote:
>> The alternative I was envisioning was to have it look at the
>> ActivePortal's query string. However, if you prefer to define the
>> function as returning the current client query, it's fine as-is.
>> We should make sure the documentation explains it lik
On Wed, 7 Jan 2009 17:22:38 -0500 (EST)
Bruce Momjian wrote:
> D'Arcy J.M. Cain wrote:
> > So what have we decided about this suggestion. Should I submit the
> > patch or just forget about it? So far some people like it and some
> > people think that it is unneccessary. No one so far has sugges
Alvaro Herrera writes:
> Bruce Momjian wrote:
>> The script certainly has no way to know it is missing an extern, and I
>> am not sure how I would even teach it that trick.
> It would be easy if the compiler were to have an option to throw a
> warning when it finds a non-static variable that does
Bruce Momjian writes:
>> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> I don't really understand this. Who can set up an inherited table
>>> structure but can't remember to turn on constraint_exclusion?
> This new change also adds the constraint exclusion overhead only for
> inhertance (by def
On Wed, 7 Jan 2009, Simon Riggs wrote:
Who can set up an inherited table structure but can't remember to turn
on constraint_exclusion?
I thought the whole point of the WIP "Auto Partitioning Patch" was exactly
to enable larger numbers of such people in the future.
--
* Greg Smith gsm...@gre
Stephen Frost wrote:
-- Start of PGP signed section.
> Simon,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > I don't really understand this. Who can set up an inherited table
> > structure but can't remember to turn on constraint_exclusion? That is
> > the easiest part of the whole process b
D'Arcy J.M. Cain wrote:
> So what have we decided about this suggestion. Should I submit the
> patch or just forget about it? So far some people like it and some
> people think that it is unneccessary. No one so far has suggested that
> it would harm the system or people's use of it.
I have gon
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I don't really understand this. Who can set up an inherited table
> structure but can't remember to turn on constraint_exclusion? That is
> the easiest part of the whole process by a long way. Nobody has this
> table design by accident, they've
On Wed, 2009-01-07 at 23:56 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
> >> When there's no xids in the procarray, couldn't we just use
> >> latestCompletedXid instead of calling ReadNewTransactionId()?
> >
> > latestCom
Bruce Momjian wrote:
> The script certainly has no way to know it is missing an extern, and I
> am not sure how I would even teach it that trick.
>
> The example you saw was:
>
> src/include/optimizer/cost.h:55:extern bool constraint_exclusion;
> src/backend/optimizer/util/plancat.c:46:bool
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module. I
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid instead of calling ReadNewTransactionId()?
latestCompletedXid is protected by ProcArrayLock so not much difference
between those two.
Le 7 janv. 09 à 22:21, Simon Riggs a écrit :
On Wed, 2009-01-07 at 12:54 -0500, Tom Lane wrote:
So, barring objections, I'll go make this happen.
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion? That is
the easi
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> We should take a second look at the usage of debug_query_string,
> >> particularly the recently added current_query() SQL function.
>
> > I looked at the use of 'debug_query_string'; I didn't see how
> > current_query() could acces
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Hiroshi Inoue wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
shouldn
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
> Another annoyance I noticed while testing
I'm sorry this has annoyed you. Thanks for testing.
> the case of a lot of
> subtransactions (overflowing the procarray cache) is that when you have
> a transaction with a lot of subtrans
Tom Lane wrote:
> I just noticed that optimizer/cost.h is not #include'd by plancat.c,
> which is not too cool because the former has the extern declaration
> for the constraint_exclusion global variable while the latter has
> the actual definition. I didn't run it down in the CVS history to
> mak
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext modul
Simon Riggs wrote:
>
> On Wed, 2009-01-07 at 12:54 -0500, Tom Lane wrote:
>
> > So, barring objections, I'll go make this happen.
>
> I don't really understand this. Who can set up an inherited table
> structure but can't remember to turn on constraint_exclusion? That is
> the easiest part of t
I just noticed that optimizer/cost.h is not #include'd by plancat.c,
which is not too cool because the former has the extern declaration
for the constraint_exclusion global variable while the latter has
the actual definition. I didn't run it down in the CVS history to
make sure, but I imagine what
On Wed, 2009-01-07 at 12:54 -0500, Tom Lane wrote:
> So, barring objections, I'll go make this happen.
I don't really understand this. Who can set up an inherited table
structure but can't remember to turn on constraint_exclusion? That is
the easiest part of the whole process by a long way. Nob
Magnus Hagander wrote:
Hiroshi Inoue wrote:
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module. I can provide it
if requested.
Yes, I think th
Bruce Momjian writes:
> Tom Lane wrote:
>> We should take a second look at the usage of debug_query_string,
>> particularly the recently added current_query() SQL function.
> I looked at the use of 'debug_query_string'; I didn't see how
> current_query() could access the more concise query strin
Tom Lane wrote:
> Log Message:
> ---
> Adjust things so that the query_string of a cached plan and the sourceText of
> a portal are never NULL, but reliably provide the source text of the query.
> It turns out that there was only one place that was really taking a short-cut,
> which was the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Hm, how about just 'partition'? Your argument is fair, and another
> point in its favor is that someday we'll probably have an explicit
> notion of partitioned tables and both the inheritance and union-view
> approaches would become legacy methods. We'd ce
> >> So, barring objections, I'll go make this happen. What do we want to
> >> call the intermediate constraint_exclusion value? The first thing
> >> that comes to mind is constraint_exclusion = 'child', but perhaps
> >> someone has a better idea.
>
> > Not a huge fan of 'child' since it implie
Tom,
Hm, how about just 'partition'? Your argument is fair, and another
point in its favor is that someday we'll probably have an explicit
notion of partitioned tables and both the inheritance and union-view
approaches would become legacy methods. We'd certainly want constraint
exclusion to ap
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So, barring objections, I'll go make this happen. What do we want to
>> call the intermediate constraint_exclusion value? The first thing
>> that comes to mind is constraint_exclusion = 'child', but perhaps
>> someone has a better
So, barring objections, I'll go make this happen. What do we want to
call the intermediate constraint_exclusion value? The first thing
that comes to mind is constraint_exclusion = 'child', but perhaps
someone has a better idea.
This is terrific. I've actually been turning c_e on and off by
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Actually, it looks like it'd be totally trivial to implement: just check
> rel->reloptkind == RELOPT_OTHER_MEMBER_REL to detect whether we're
> looking at an inheritance child. (Actually this would also succeed
> for a UNION ALL member, but that's good beca
> So, barring objections, I'll go make this happen. What do we want to
> call the intermediate constraint_exclusion value? The first thing
> that comes to mind is constraint_exclusion = 'child', but perhaps
> someone has a better idea.
"inherit"?
...Robert
--
Sent via pgsql-hackers mailing li
Tom Lane wrote:
> I wrote:
> > I just thought of a possible compromise though: maybe we could invent an
> > intermediate constraint_exclusion setting that makes the checks only for
> > inheritance-child tables. This would avoid the overhead for simple
> > queries and still get the benefit for most
I wrote:
> I just thought of a possible compromise though: maybe we could invent an
> intermediate constraint_exclusion setting that makes the checks only for
> inheritance-child tables. This would avoid the overhead for simple
> queries and still get the benefit for most of the cases where it's
>
On Wed, 2009-01-07 at 12:26 -0500, Robert Haas wrote:
> > ~ 10% slowdown on trivial queries will get noticed.
> > I just thought of a possible compromise though: maybe we could invent an
> > intermediate constraint_exclusion setting that makes the checks only for
> > inheritance-child tables. Thi
> ~ 10% slowdown on trivial queries will get noticed.
Agreed.
> I just thought of a possible compromise though: maybe we could invent an
> intermediate constraint_exclusion setting that makes the checks only for
> inheritance-child tables. This would avoid the overhead for simple
> queries and s
"Joshua D. Drake" writes:
> On Wed, 2009-01-07 at 10:59 -0500, Tom Lane wrote:
>> In installations whose average query is significantly heavier-weight
>> than this one, and where constraint exclusion actually improves matters
>> on a routine basis, it makes sense to turn it on by default. I will
Greg Stark wrote:
>
> On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
>
> > Heikki Linnakangas wrote:
> >> It's required by the sync replication patch, but has no value
> >> otherwise.
> >
> > Well, we have talked about allowing more signalling long-term, and
> > this
> > would accomplish that
On Wed, 2009-01-07 at 10:59 -0500, Tom Lane wrote:
> "Robert Haas" writes:
> > On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian wrote:
> >> Based on the comments below, are we sure constraint_exclusion still
> >> needs to be a parameter and can't be on by default?
> In installations whose average
On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
Heikki Linnakangas wrote:
It's required by the sync replication patch, but has no value
otherwise.
Well, we have talked about allowing more signalling long-term, and
this
would accomplish that independent of the sync replication, so we might
I've also thought a similar implementation but there seems
a problem of efficiency.
As far as I see wcsftime() is almost = strftime() + mbstowcs()
and so using strftime() is effective at least for the following
cases.
1) LC_CTIME is "C".
2) LC_CTYPE != C and the database encoding != UTF-8. In th
Sam Mason writes:
> This example does seem to be confounded by PG's somewhat eccentric type
> system. Things would "just work" (in this case, and there have been
> other cases recently[1]) if type decisions could be delayed slightly.
There's been previous speculation about having numeric literal
On Wed, Jan 07, 2009 at 11:17:46AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > [ good summary ]
>
> +1 for making TRUNCATE and LOCK support ONLY. I don't care much
> about ALTER TABLE SET SCHEMA, but perhaps there's a use-case for
> recursion on that. We should stay away from recursiv
ITAGAKI Takahiro wrote:
Hiroshi Inoue wrote:
Seems LC_CTYPE and LC_TIME should be convertible even though we use
wcsftime (which internally calls strftime?).
Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
(at least encoding) on Windows.
The attached patch is an updat
On Wed, Jan 07, 2009 at 09:56:48AM -0500, Tom Lane wrote:
> "Nikhil Sontakke" writes:
> > Consider the following with latest CVS sources:
>
> > postgres=# create table temp(val float4);
> > CREATE TABLE
> > postgres=# insert into temp values (415.1);
> > INSERT 0 1
> > postgres=# select * from te
Peter Eisentraut writes:
> [ good summary ]
+1 for making TRUNCATE and LOCK support ONLY. I don't care much about
ALTER TABLE SET SCHEMA, but perhaps there's a use-case for recursion
on that. We should stay away from recursive CREATE INDEX for the
moment --- for one thing, you'd have to invent
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Where are we on this?
AFAICS there are 2 causes.
1. MSVC version of postgres is using a bad gettext module.
2. getenv() in mingw cannot see the result of putenv() in MSVC8.0.
As for 1, we have to use another gettext module. I
"Robert Haas" writes:
> On Wed, Jan 7, 2009 at 12:15 AM, Bruce Momjian wrote:
>> Based on the comments below, are we sure constraint_exclusion still
>> needs to be a parameter and can't be on by default?
> The benchmarking we did to determine the impact of raising
> default_statistics_target was
Tom Lane wrote:
I note though that we have a lot of other non-recursive maintenance
operations (CLUSTER, some variants of ALTER TABLE, etc) ... are we
going to try to make them all recursive?
Here is the current line-up:
command supports ONLY
ALTER TABLE all other acti
Pavan Deolasee wrote:
> On Wed, Jan 7, 2009 at 1:23 AM, Bruce Momjian wrote:
> > Tom Lane wrote:
>
> >
> >> As-is, this list is completely unhelpful. It looks like you've dumped
> >> all your unread mail onto this page and asked the rest of us to sort it
> >> for you. I'm sorry, but I've got ot
Zdenek Kotala wrote:
>
> Robert Haas p??e v ?t 06. 01. 2009 v 12:38 -0500:
>
> > - WIP: Page space reservation (pgupgrade) is an idea that was
> > rejected, IIRC. pg_upgrade project status is more of the same thing.
> > there are several more pg_upgrade related items on here as well, most
> > of
>>> Peter Eisentraut wrote:
> Kevin Grittner wrote:
>>> "is a natural consequence of the fact" --- There is nothing
>>> natural about any of this. Why is it a consequence and how?
>>
>> How could you possibly get any of those phenomena if there are no
>> concurrent transactions?
>
> I see wha
On Wed, Jan 07, 2009 at 08:12:44PM +0530, Nikhil Sontakke wrote:
> Hi,
>
> Consider the following with latest CVS sources:
>
> postgres=# create table temp(val float4);
> CREATE TABLE
> postgres=# insert into temp values (415.1);
> INSERT 0 1
> postgres=# select * from temp where val = 415.1;
>
"Nikhil Sontakke" writes:
> Consider the following with latest CVS sources:
> postgres=# create table temp(val float4);
> CREATE TABLE
> postgres=# insert into temp values (415.1);
> INSERT 0 1
> postgres=# select * from temp where val = 415.1;
Anybody who works with float arithmetic can tell yo
On Wed, Jan 07, 2009 at 08:12:44PM +0530, Nikhil Sontakke wrote:
> Hi,
>
> Consider the following with latest CVS sources:
>
> postgres=# create table temp(val float4);
> CREATE TABLE
> postgres=# insert into temp values (415.1);
> INSERT 0 1
> postgres=# select * from temp where val = 415.1;
>
Hi,
Consider the following with latest CVS sources:
postgres=# create table temp(val float4);
CREATE TABLE
postgres=# insert into temp values (415.1);
INSERT 0 1
postgres=# select * from temp where val = 415.1;
val
-
(0 rows)
!?
The reason seems to be that 415.1 ends up being treated as a
Heikki Linnakangas wrote:
> It's required by the sync replication patch, but has no value otherwise.
Well, we have talked about allowing more signalling long-term, and this
would accomplish that independent of the sync replication, so we might
want to revisit this someday if it isn't included in s
On Fri, Jan 2, 2009 at 5:48 PM, Martijn van Oosterhout
wrote:
> So you compromise. You split the data into say 1MB blobs and compress
> each individually. Then if someone does a substring at offset 3MB you
> can find it quickly. This barely costs you anything in the compression
> ratio mostly.
>
>
Martin Pihlak writes:
> As I understand the autovacuum workers need up to date stats to minimize the
> risk of re-vacuuming a table (in case it was already vacuumed by someone
> else).
I never understood why autovacuum should need a particularly short fuse
on the stats file age to start with. I
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Is it possible to implement a walker function to pick up appeared
>> columns and to chain them on rte->cols_sel/cols_mod?
>> In this idea, columns in Query->targetList should be chained on
>> rte->cols_mod, and others should be chained on rte
On Tue, Jan 06, 2009 at 11:49:57PM -0500, Robert Haas wrote:
> Josh / eggyknap -
>
> Can you rerun your performance tests with this version of the patch?
>
> ...Robert
Will do, as soon as I can.
signature.asc
Description: Digital signature
Alvaro Herrera writes:
> Oh, the patch also removes a bunch of "continue" statements that, as far
> as I can tell, no longer work after the macros were wrapped in
> do { ... } while (0) :-( I don't see any nice way to put the facility
> back.
Hmm ... I guess you could make the wrapping be "if (.
1 - 100 of 132 matches
Mail list logo
