Ühel kenal päeval, N, 2007-03-22 kell 23:30, kirjutas Pavan Deolasee:
On 3/22/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
When CREATE INDEX starts, it acquires ShareLock on the
table.
At this point we may have one or
Ü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 what
Ü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 much simpler to me do
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 CREATE
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
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
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
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,
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
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 for
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 we have the
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
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
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 documents
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
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.
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 means
me too /aolmode
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.
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 fixing
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 hard to
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 personally.
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
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
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
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.
I wonder
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. It
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, 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. I'm
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 mm high, but I'd
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 and
Preview,
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 doesn't have thin
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
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 is:
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 one size
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 contribute
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 may be
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
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
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 easy
Matthew T. O'Connor matthew@zeut.net 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
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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
Bruce Momjian wrote:
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net 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.
[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
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.tranNo = A.tranNo)
WHERE H.tranType = 'A'
AND
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 of
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 A
JOIN TranHeader H ON (H.tranId =
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.
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 kleptog@svana.org 03/23/07
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.
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%'
)
That's the good news. The bad news is that I
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.
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 allow that
52 matches
Mail list logo
