Tom Lane wrote:
> Itagaki Takahiro writes:
> > "make installcheck" seems to be broken in HEAD on mingw for a few days,
> > though it ran sucessfully on Linux.
>
> The mingw buildfarm machines seem to be happy. Are you sure you
> have a clean build?
Yes, but distclean and deleting auto-genera
Well, i am at a very beginner level with Flex. I could see how flex works
with it even if it is a ambiguity. Since it matches the rule with the
maximum text and we don't allow a new line character in the rule, it works
fine. Even in LL(1), it works fine, but throws warnings. So i just thought
of s
On Tue, Sep 1, 2009 at 9:55 PM, Robert Haas wrote:
>
> I'm a bit skeptical about partitioning as a solution, too. The
> planner is just not clever enough with partitioned tables, yet.
>
analyze and vacuum a *very* big table and even scan a huge index is
not a joke neither...
and yes the planner i
I posted a message a little over a week ago discussing the timetable for 8.5:
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01576.php
That thread went off on a number of interesting tangents which I found
pretty informative. Probably the most interesting one to me
personally was about
On Tue, Sep 1, 2009 at 19:34, Greg Stark wrote:
> On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
> Herrera wrote:
> >> The use cases where VACUUM FULL wins currently are where storing two
> >> copies of the table and its indexes concurrently just isn't practical.
> >
> > Yeah, but then do you really nee
Gokulakannan Somasundaram writes:
> I have replaced whitespace with space. This has to be done because
> whitespace allows comments. This would cause conflict between some of the
> alternatives. I found this, while trying to make this rule work with LL(1).
Um, if it's ambiguous, why doesn't flex
On Tue, Sep 1, 2009 at 10:58 PM, Alvaro
Herrera wrote:
> Robert Haas escribió:
>> On Tue, Sep 1, 2009 at 7:42 PM, Tom Lane wrote:
>
>> > But trying to VACUUM FULL that table is going to be horridly painful
>> > too, and you'll still have bloated indexes afterwards. You might as
>> > well just live
Robert Haas escribió:
> On Tue, Sep 1, 2009 at 7:42 PM, Tom Lane wrote:
> > But trying to VACUUM FULL that table is going to be horridly painful
> > too, and you'll still have bloated indexes afterwards. You might as
> > well just live with the 50% waste, especially since if you did a
> > full-ta
On Tue, Sep 1, 2009 at 9:29 PM, Alvaro
Herrera wrote:
> Ron Mayer wrote:
>> Greg Stark wrote:
>> >
>> > That's what I want to believe. But picture if you have, say a
>> > 1-terabyte table which is 50% dead tuples and you don't have a spare
>> > 1-terabytes to rewrite the whole table.
>>
>> Could on
On Tue, Sep 1, 2009 at 7:42 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
>> Herrera wrote:
The use cases where VACUUM FULL wins currently are where storing two
copies of the table and its indexes concurrently just isn't practical.
>>>
>>> Yeah, but
Itagaki Takahiro writes:
> "make installcheck" seems to be broken in HEAD on mingw for a few days,
> though it ran sucessfully on Linux.
The mingw buildfarm machines seem to be happy. Are you sure you
have a clean build?
regards, tom lane
--
Sent via pgsql-hackers mail
Ron Mayer wrote:
> Greg Stark wrote:
> >
> > That's what I want to believe. But picture if you have, say a
> > 1-terabyte table which is 50% dead tuples and you don't have a spare
> > 1-terabytes to rewrite the whole table.
>
> Could one hypothetically do
>update bigtable set pk = pk where ct
There is a rule like this in scan.l
uescapefail
("-"|[uU][eE][sS][cC][aA][pP][eE]{whitespace}*"-"|[uU][eE][sS][cC][aA][pP][eE]{whitespace}*{quote}[^']|[uU][eE][sS][cC][aA][pP][eE]{whitespace}*{quote}|[uU][eE][sS][cC][aA][pP][eE]{whitespace}*|[uU][eE][sS][cC][aA][pP]|[uU][eE][sS][cC][aA]|[uU][eE][s
Kevin Grittner wrote:
We're using SLES10. If we installed the latest from the SuSE site, we
would be at PostgreSQL version 8.1. Now, to their credit, that is
8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
whether to go back to 8.1.
I recently build 8.4 RPMs for SL
"make installcheck" seems to be broken in HEAD on mingw for a few days,
though it ran sucessfully on Linux.
$ cd contrib/citext/
$ make installcheck
make -C ../../src/test/regress pg_regress.exe
make[1]: Entering directory `/d/projects/head/src/test/regress'
make[1]: `pg_regress.exe' is up to date
On Sep 1, 2009, at 6:43 PM, Tom Lane wrote:
Debatable, but it's not upstream default, so why should it be
downstream
default?
FWIW, that particular issue is invariably a matter of distro policy;
they could care less what upstream's default is.
Well, they could, but do they?
/me offers Tom
The previous change should follow with this.
uescape[uU][eE][sS][cC][aA][pP][eE]{space}*{quote}[^']{quote}
Thanks,
Gokul.
On Wed, Sep 2, 2009 at 7:35 AM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
> There is a rule like this in scan.l
>
> uescapefail
> ("-"|[uU][eE][sS][
Peter Eisentraut writes:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
>> And unless I'm remembering incorrectly, the configure options are not
>> what we would want. I don't see any reason the packaged build
>> shouldn't be with --enable-debug on a platform where that has no
>> perf
Greg Stark wrote:
>
> That's what I want to believe. But picture if you have, say a
> 1-terabyte table which is 50% dead tuples and you don't have a spare
> 1-terabytes to rewrite the whole table.
Could one hypothetically do
update bigtable set pk = pk where ctid in (select ctid from bigtable
On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
> We're using SLES10. If we installed the latest from the SuSE site, we
> would be at PostgreSQL version 8.1. Now, to their credit, that is
> 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
> whether to go back to 8.1.
Greg Stark writes:
> On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
> Herrera wrote:
>>> The use cases where VACUUM FULL wins currently are where storing two
>>> copies of the table and its indexes concurrently just isn't practical.
>>
>> Yeah, but then do you really need to use VACUUM FULL? If that's
On Wed, Sep 2, 2009 at 12:01 AM, Alvaro
Herrera wrote:
>> The use cases where VACUUM FULL wins currently are where storing two
>> copies of the table and its indexes concurrently just isn't practical.
>
> Yeah, but then do you really need to use VACUUM FULL? If that's really
> a problem then there
Greg Stark wrote:
> The use cases where VACUUM FULL wins currently are where storing two
> copies of the table and its indexes concurrently just isn't practical.
Yeah, but then do you really need to use VACUUM FULL? If that's really
a problem then there ain't that many dead tuples around.
> Als
On Tue, Sep 1, 2009 at 2:58 PM, Tom Lane wrote:
> We get beat up on a regular basis about "spikes" in response time;
> why would you want to have vacuum creating one when it doesn't need to?
Isn't this sync commit just going to do the same thing that the wal
writer is going to do in at most 200ms
On tis, 2009-09-01 at 11:41 -0700, Josh Berkus wrote:
> Opinions? Other objects which could take \e?
All of them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus wrote:
All,
I've grown to adore the new \ef function editor.
It doesn't seem like it would be that difficult to add a view editor as
\ev. While editors would also be good for other objects, I don't think
we can do \et or \er etc. because those objects don't support CREATE OR
REPL
On Mon, Aug 31, 2009 at 3:32 PM, Greg Sabino Mullane wrote:
> Just noticed in the release notes for 8.4, there are two items
> accredited to just "Greg" (but there are three of us Gregs who
> contributed to 8.4 and are in the notes). While this is very likely
> Greg Stark, due to the context, I thi
Christopher Browne wrote:
g...@turnstep.com ("Greg Sabino Mullane") writes:
(Enjoy while you can, Bruce, we'll get another Bruce to contribute
someday! Zoltan might be harder... :)
My middle name is Bruce; there wouldn't be any "legal humps" to overcome
for me to use the moniker "Bru
On Tue, Sep 1, 2009 at 3:01 PM, David Fetter wrote:
> On Tue, Sep 01, 2009 at 02:29:12PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > I think we should always or never show the view definition, not
>> > sometimes.
>>
>> Yeah. I can live with \d not showing it and \d+ showing it --- as
>> Pe
On Tue, Sep 01, 2009 at 11:41:31AM -0700, Josh Berkus wrote:
> All,
>
> I've grown to adore the new \ef function editor.
>
> It doesn't seem like it would be that difficult to add a view editor as
> \ev. While editors would also be good for other objects, I don't think
> we can do \et or \er etc
On Tue, Sep 01, 2009 at 02:29:12PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > I think we should always or never show the view definition, not
> > sometimes.
>
> Yeah. I can live with \d not showing it and \d+ showing it --- as
> Peter already mentioned, that would be consistent with \df be
All,
I've grown to adore the new \ef function editor.
It doesn't seem like it would be that difficult to add a view editor as
\ev. While editors would also be good for other objects, I don't think
we can do \et or \er etc. because those objects don't support CREATE OR
REPLACE.
Opinions? Other
Robert Haas wrote:
> I think we should always or never show the view definition, not
> sometimes.
+1
> And I also agree with Tom's point that we should fix the pager. The
> way that it works now is really annoying.
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
I'm getting this same error and wonder if Tom's fix is sufficient.
IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT >= 0x0501, but in
pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so IPPROTO_IPV6 is left
undefined.
Regards,
Dave
---
Unfortunately I had to uninstall VS20
Robert Haas writes:
> I think we should always or never show the view definition, not sometimes.
Yeah. I can live with \d not showing it and \d+ showing it --- as Peter
already mentioned, that would be consistent with \df behavior. Making
it depend on the length is just weird.
g...@turnstep.com ("Greg Sabino Mullane") writes:
> (Enjoy while you can, Bruce, we'll get another Bruce to contribute
> someday! Zoltan might be harder... :)
My middle name is Bruce; there wouldn't be any "legal humps" to overcome
for me to use the moniker "Bruce Browne" :-).
--
output = reverse
On Tue, Sep 1, 2009 at 1:31 PM, Josh Berkus wrote:
> On 8/31/09 1:13 PM, Peter Eisentraut wrote:
>> I guess my premise is that if I use \d, I'm primarily interested in the
>> column names and types. The view definition is secondary. If the view
>> definition is a single line or uses a single tabl
Simon Riggs writes:
> On Tue, 2009-09-01 at 09:58 -0400, Tom Lane wrote:
>> We get beat up on a regular basis about "spikes" in response time;
>> why would you want to have vacuum creating one when it doesn't need
>> to?
> If one I/O on a background utility can cause such a spike, we are in
> ser
On 8/31/09 1:13 PM, Peter Eisentraut wrote:
> I guess my premise is that if I use \d, I'm primarily interested in the
> column names and types. The view definition is secondary. If the view
> definition is a single line or uses a single table, it's interesting
> because it might describe somethin
On Tue, 2009-09-01 at 09:58 -0400, Tom Lane wrote:
> We get beat up on a regular basis about "spikes" in response time;
> why would you want to have vacuum creating one when it doesn't need
> to?
If one I/O on a background utility can cause such a spike, we are in
serious shitake. I would be mor
Peter Eisentraut wrote:
> On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote:
>> the SuSE distribution's version of PostgreSQL is so out-of-date
>> that we don't install it. It also doesn't enable debug info or
>> integer date times.
> Fixes and help are welcome, btw.
We're using SLES
Alvaro Herrera writes:
> So, I think InitPostgres API could be deuglified a bit more by having
> the launcher pass the database name instead of the OID.
Huh? You mean workers? Where are they going to get the name from?
The AV shmem structures carry OIDs no?
regards, tom
Simon Riggs writes:
> VACUUM does so many things that I'd rather have it all safely on disk.
> I'd feel happier with the rule "VACUUM always sync commits", so we all
> remember it and can rely upon it to be the same from release to release.
Non-FULL vacuum has *never* done a sync commit, except i
Tom Lane wrote:
> Log Message:
> ---
> Move processing of startup-packet switches and GUC settings into InitPostgres,
> to fix the problem that SetClientEncoding needs to be done before
> InitializeClientEncoding, as reported by Zdenek Kotala. We get at least
> the small consolation of bei
The thing is I was in a project to develop a Fuzzy Database Management
System. We have to bring fuzzy logic to postgresql, there was a team
developing a software in java and the other developing in the
postgresql core. But I always think these were wrong, so I'm trying to
develop a library to do th
On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote:
> My counter-argument to that would be that the SuSE distribution's
> version of PostgreSQL is so out-of-date that we don't install it. It
> also doesn't enable debug info or integer date times. So we switched
> to build from source before
On mån, 2009-08-31 at 20:54 -0400, Greg Smith wrote:
> On Mon, 31 Aug 2009, Kevin Grittner wrote:
>
> > My counter-argument to that would be that the SuSE distribution's
> > version of PostgreSQL is so out-of-date that we don't install it.
>
> Given that it's also RPM based, is it possible to get
Bruce Momjian írta:
> Greg Sabino Mullane wrote:
> [ There is text before PGP section. ]
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>> Just noticed in the release notes for 8.4, there are two items
>> accredited to just "Greg" (but there are three of us Gregs who
>> contribute
I've been idly thinking about binary COPY and recent performance efforts
spent on it. The main problem I have with binary output is that I never
know when it'll be any useful (except very same hardware and PostgreSQL
setup)... useful meaning I get to read it back into some database.
I posted a
Dimitri Fontaine wrote:
> Hi,
>
> I've been idly thinking about binary COPY and recent performance efforts
> spent on it. The main problem I have with binary output is that I never
> know when it'll be any useful (except very same hardware and PostgreSQL
> setup)... useful meaning I get to read it
On 9/1/09, Dimitri Fontaine wrote:
> I've been idly thinking about binary COPY and recent performance efforts
> spent on it. The main problem I have with binary output is that I never
> know when it'll be any useful (except very same hardware and PostgreSQL
> setup)... useful meaning I get to
On Mon, Aug 31, 2009 at 21:49, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Well, I'm not sure the average user knows or cares about the difference
>>> between the launcher and the workers. The thing that was in the back of
>>> my mind was that we would now have the option to h
Hi,
I've been idly thinking about binary COPY and recent performance efforts
spent on it. The main problem I have with binary output is that I never
know when it'll be any useful (except very same hardware and PostgreSQL
setup)... useful meaning I get to read it back into some database.
Would pro
On Mon, 2009-08-31 at 18:53 -0400, Alvaro Herrera wrote:
> Regarding sync commits that previously happen and now won't, I think the
> only case worth worrying about is the one in vacuum.c. Do we need a
> ForceSyncCommit() in there? I'm not sure if vacuum itself already
> forces sync commit.
VA
54 matches
Mail list logo
