>>> On Fri, Mar 23, 2007 at 6:04 PM, in message
<[EMAIL PROTECTED]>, "Peter Kovacs"
<[EMAIL PROTECTED]> wrote:
> On 3/23/07, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> [...]
>> That's the good news. The bad news is that I operate under a management
> portability dictate which doesn't currently
Hello,
We have had several customers get bit by the 8.2.3 stats collector bug.
It is also starting to get reported in areas such as IRC. The really bad
thing about this bug is that you won't know what is wrong unless you
know where to look, PostgreSQL will just appear slow and tying up resources.
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> If you want that, try rewriting the EXISTS to an IN:
>>
>> AND ("H"."tranNo", "H"."countyNo") IN
>> (
>> SELECT "D"."tranNo", "D"."countyNo" FROM "TranDetail" "D"
>> WHERE "D"."caseNo" LIKE '2006TR%'
>> )
> Tha
>>> On Fri, Mar 23, 2007 at 5:26 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
> I tried something which seems
> equivalent, but it is running for a very long time. I'll show it with just
> the explain while I wait to see how long the explain analyze takes.
I don't understand -- TRUE OR UNKNOWN evaluates to TRUE, so why would the IN
need to continue? I'm not quite following the rest; could you elaborate or
give an example? (Sorry if I'm lagging behind the rest of the class here.)
-Kevin
>>> Martijn van Oosterhout 03/23/07 5:26 PM >>>
On Fr
On Fri, Mar 23, 2007 at 05:49:42PM -0400, Tom Lane wrote:
> We don't currently try to flatten EXISTS into a unique/join plan as we
> do for IN. I seem to recall not doing so when I rewrote IN planning
> because I didn't think it would be exactly semantically equivalent,
> but that was awhile ago.
>>> On Fri, Mar 23, 2007 at 4:49 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> explain analyze
>> SELECT "A"."adjustmentNo", "A"."tranNo", "A"."countyNo", "H"."date",
> "H"."userId", "H"."time"
>> FROM "Adjustment" "
Tom Lane wrote:
> [EMAIL PROTECTED] (Alvaro Herrera) writes:
> > We no longer need to palloc the VacuumStmt node; keeping it on the stack is
> > simpler.
>
> If you're going to do that, you should at least set the nodeTag so that
> the struct appears valid to onlookers. A memset wouldn't be out o
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> explain analyze
> SELECT "A"."adjustmentNo", "A"."tranNo", "A"."countyNo", "H"."date",
> "H"."userId", "H"."time"
> FROM "Adjustment" "A"
> JOIN "TranHeader" "H" ON ("H"."tranId" = "A"."adjustmentNo" AND
> "H"."countyNo" = "A"."countyNo" AND "H".
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> We no longer need to palloc the VacuumStmt node; keeping it on the stack is
> simpler.
If you're going to do that, you should at least set the nodeTag so that
the struct appears valid to onlookers. A memset wouldn't be out of
place either to make sure
Bruce Momjian wrote:
Tom Lane wrote:
"Matthew T. O'Connor" writes:
Lots of projects publish their HTML docs in two formats: One Big HTML
file with everything; Broken up into many HTML files that link to each
other. This would allow you you have one big searchable document.
The key word ther
Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Lots of projects publish their HTML docs in two formats: One Big HTML
> > file with everything; Broken up into many HTML files that link to each
> > other. This would allow you you have one big searchable document.
>
> The key word there bein
"Matthew T. O'Connor" writes:
> Lots of projects publish their HTML docs in two formats: One Big HTML
> file with everything; Broken up into many HTML files that link to each
> other. This would allow you you have one big searchable document.
The key word there being "big" ;-) ... I don't have
Matthew T. O'Connor wrote:
> Joshua D. Drake wrote:
> > The big thing for me, is a single document, zero clicks, that is
> > searchable. PDF and plain text are the only thing that give me that. If
> > you are really zealous you can even use Beagle (which I don't) to
> > preindex the PDF for you for
Joshua D. Drake wrote:
The big thing for me, is a single document, zero clicks, that is
searchable. PDF and plain text are the only thing that give me that. If
you are really zealous you can even use Beagle (which I don't) to
preindex the PDF for you for easy searching.
Lots of projects publish
Hugh Sasse wrote:
> I wrote :
>>> Ah, so the HTML is the source,
>
> On Fri, 23 Mar 2007, Joshua D. Drake wrote:
>> No, docbook is the source of which you apply DSSSL to to generate PS,
>> PDF, HTML, XML, Latex etc..
>
> OK, well I need to become familiar with docbook for other projects, so
>
>
I wrote :
> >
> > Ah, so the HTML is the source,
On Fri, 23 Mar 2007, Joshua D. Drake wrote:
>
> No, docbook is the source of which you apply DSSSL to to generate PS,
> PDF, HTML, XML, Latex etc..
OK, well I need to become familiar with docbook for other projects, so
I may be able to con
On Fri, 23 Mar 2007, Andrew Dunstan wrote:
> Hugh Sasse wrote:
> > I'd like to improve it for me and others
> > in my position without making it typographically hideous for fully sighted
> > people :-).
> There is no reason we cannot produce several versions of the docs. It doesn't
> have to be o
> The samples are on A5 rather than A4. I wonder if the PostgreSQL docs
> were output to A$ whether that might help me, because I'd be able to
> double the size before lines flowed off the screen? Thanks for this
> info about Gentium -- I rather like it.
>>> I suppose the question to ask now i
Hugh Sasse wrote:
I'd like to improve it for me and others
in my position without making it typographically hideous for fully sighted
people :-).
There is no reason we cannot produce several versions of the docs. It
doesn't have to be one size fits all.
cheers
andrew
--
On Fri, 23 Mar 2007, Alvaro Herrera wrote:
> Hugh Sasse wrote:
> > On Fri, 23 Mar 2007, Joshua D. Drake wrote:
> >
> > > Hugh Sasse wrote:
> > >
> > > > It's a variable function of my vision, lighting, but I usually use 24
> > > > point
> > > > on VDUs, In this terminal (because Lucida Console
On Fri, 23 Mar 2007, Joshua D. Drake wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> It should be standard docs imo. PDF is a heck of a lot easier to read if
> >> you have a good PDF reader.
> >
> > Just out of curiosity, what would that be? I've used both Acrobat
Hugh Sasse wrote:
> On Fri, 23 Mar 2007, Joshua D. Drake wrote:
>
> > Hugh Sasse wrote:
> >
> > > It's a variable function of my vision, lighting, but I usually use 24
> > > point
> > > on VDUs, In this terminal (because Lucida Console doesn't have thin
> > > strokes,
> > > the n's are about 5
I'm posting this to performance in case our workaround may be of benefit to
someone with a similar issue. I'm posting to hackers because I hope we can
improve our planner in this area so that a workaround is not necessary. (It
might make sense to reply to one group or the other, depending on r
On Fri, 23 Mar 2007, Joshua D. Drake wrote:
> Hugh Sasse wrote:
>
> > It's a variable function of my vision, lighting, but I usually use 24 point
> > on VDUs, In this terminal (because Lucida Console doesn't have thin strokes,
> > the n's are about 5 mm high, but I'd like them bigger if possible.
Hugh Sasse wrote:
> It's a variable function of my vision, lighting, but I usually use 24 point
> on VDUs, In this terminal (because Lucida Console doesn't have thin strokes,
> the n's are about 5 mm high, but I'd like them bigger if possible. I'm
> not the limiting case, a former colleague liked
On Fri, 23 Mar 2007, Peter Eisentraut wrote:
> Am Freitag, 23. M?rz 2007 15:15 schrieb Hugh Sasse:
> > The PDFs are of high quality in terms of effort and content, but I
> > can't get the text large enough to see
You trimmed that -- it is large enough if I can put up with non-smooth
scrolling. I
Peter Eisentraut wrote:
> Am Freitag, 23. März 2007 15:15 schrieb Hugh Sasse:
>> The PDFs are of high quality in terms of effort and content, but I
>> can't get the text large enough to see
>
> How large would you need it to be? I can zoom both the PDF and the HTML so
> that an "n" is 5mm high.
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
...
It seems that somehow the system provided
GCC 3.4.3 miscompiles timestamptz_send()
and it segfaults.
I fi
Am Freitag, 23. März 2007 15:15 schrieb Hugh Sasse:
> The PDFs are of high quality in terms of effort and content, but I
> can't get the text large enough to see
How large would you need it to be? I can zoom both the PDF and the HTML so
that an "n" is 5mm high.
--
Peter Eisentraut
http://devel
Zdenek Kotala írta:
Zoltan Boszormenyi wrote:
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V440
It seems that somehow the system provided
GCC
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> It should be standard docs imo. PDF is a heck of a lot easier to read if
>> you have a good PDF reader.
>
> Just out of curiosity, what would that be? I've used both Acrobat and
> Preview, and I do not like either.
I use Evince p
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> we have found that psql in PostgreSQL 8.2.3
> has problems connecting to the server
> running on Solaris 10/Sun SPARC.
> ...
> It seems that somehow the system provided
> GCC 3.4.3 miscompiles timestamptz_send()
> and it segfaults.
I find it fairly
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> It should be standard docs imo. PDF is a heck of a lot easier to read if
> you have a good PDF reader.
Just out of curiosity, what would that be? I've used both Acrobat and
Preview, and I do not like either.
(As to the original point, I'm all for f
> me too
>
> I do think though that there is a good case for producing PDFs for sight
> impaired people, on pgfoundry if not as part of our standard docs
> production.
It should be standard docs imo. PDF is a heck of a lot easier to read if
you have a good PDF reader. Not to mention print.
Jos
Tom Lane wrote:
Hugh Sasse <[EMAIL PROTECTED]> writes:
... I have found the Web versions, but don't know
how much (if anything) is lost in making the documents fit HTML.
Nothing --- the HTML version is what I invariably consult. So if you
have decent reader tools for HTML, by all mean
Hugh Sasse <[EMAIL PROTECTED]> writes:
> ... I have found the Web versions, but don't know
> how much (if anything) is lost in making the documents fit HTML.
Nothing --- the HTML version is what I invariably consult. So if you
have decent reader tools for HTML, by all means go with that.
Zoltan Boszormenyi wrote:
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V440
It seems that somehow the system provided
GCC 3.4.3 miscompiles ti
Hugh Sasse wrote:
> If this is too difficult, I have found the Web versions, but don't know
> how much (if anything) is lost in making the documents fit HTML.
I suggest you read the HTML pages. The information is the same. In
fact, I think the question is "how much is lost in making the documen
I'm new to PostgreSQL, having done a little work with MySQL in the
past. Part of the reason for changing to PostgreSQL is some of the
differences but to understand them I need docs of course. Now there
are plenty of books, but I can't find any to examine in local
bookshops (pretty poor for a town
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V440
It seems that somehow the system provided
GCC 3.4.3 miscompiles timestamptz_send()
and it seg
Pavan Deolasee wrote:
> > Xids are unstable and will come back to bite you after 2G transactions.
> >
> > Why not just use the "isindvalid" flag ?
> >
> >
> Who would set the flag to true ? Unless of course we are waiting in
> CREATE INDEX. But that seems to be less acceptable to me.
Agreed, and w
Hannu Krosing wrote:
> I don't think it is a good idea to store xid's anywhere but in xmin/xmax
> columns, as doing so would cause nasty xid wraparound problems.
>
> Instead you should wait, after completeing the index , for all
> concurrent transactions to end before you mark the index as "usable
Pavan Deolasee wrote:
On 3/23/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Why exactly can't a SERIALIZABLE transaction use the index it created
itself? If you add a pointer to the root of all HOT update chains where
either the HEAD is alive, or some tuple is visible to the transaction
crea
On 3/23/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Why exactly can't a SERIALIZABLE transaction use the index it created
itself? If you add a pointer to the root of all HOT update chains where
either the HEAD is alive, or some tuple is visible to the transaction
creating the index, shouldn
Teodor Sigaev wrote:
For given schema and server's locale, it's possible to have several FTS
configurations, but the only one (with special flag enabled)
could be used as default. Current (active) FTS configuration contains
in GUC variable tsearch_conf_name. If it's not defined, then FTS
config
Pavan Deolasee wrote:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data, but I don't think anybody is going to
complain about that restriction. Anyone?
Oh, I did not se
http://www.sigaev.ru/misc/tsearch_core-0.41.gz
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Changes
1) added command
ALTER FULLTEXT MAPPING ON cfgname [FOR lexemetypename[, ...]] REPLACE
olddictname TO newdictname;
2) added operator class for text and varchar
CREATE INDEX idxname ON tblname
On 3/23/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> My argument is that its enough to index only the LIVE tuple which
> is at the end of the chain if we don't use the new index for queries
> in transactions which were started before CREATE INDEX.
You mean, which were started before CREAT
Ühel kenal päeval, K, 2007-03-21 kell 14:06, kirjutas Merlin Moncure:
> On 3/21/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
> > Pavan Deolasee wrote:
> > > On 3/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > >>
> > >> On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> > >> > It seems
Ühel kenal päeval, N, 2007-03-22 kell 07:09, kirjutas Andrew Dunstan:
> Pavan Deolasee wrote:
> > What I am hearing from many users is that its probably not such
> > a nice thing to put such restriction. Thats fair. It really helps to think
> > about a solution once you know what is acceptable and
51 matches
Mail list logo
