"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Proposed changes:
> 1. Add function contains()
> 2. Alter docs to show use of contains()
>
> All other @@ features still the same
Have you yet given any advantages of contains over @@ ?
--
Gregory Stark
EnterpriseDB http://www.enterprised
On Tue, 2007-11-13 at 14:36 -0500, Greg Smith wrote:
> On Tue, 13 Nov 2007, Andrew Sullivan wrote:
>
> > I have to agree with what Tom says, however, about people thinking
> > they're smarter than the system. Much of the time, this sort of thumb
> > on the scale optimisation just moves the cost
On Tue, 2007-11-13 at 08:58 +0100, Pavel Stehule wrote:
> On 13/11/2007, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > I'm thinking we can have an inlinable function
> >
> > contains(text, text) returns int
> >
> > Return values limited to just 0 or 1 or NULL, as with SQL/MM.
> > It's close to SQL/MM,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I tried something like that briefly and it failed. The trouble is, I
> think, that since the engine tries a require it fails on the op test
> before it even looks to see if the module is already loaded.
I think we have little choice but to report this
> ... Therefore, we have to tell people
> to use some other API anyway. The existing tsearch2 API at least has
> the virtue of having been proven in the field over several years.
I can only speak as a moderately sophisticated end user, but ... I
think the tsearch2 API has been "proven" to alienat
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The fact that we are having this discussion at all demonstrates to me
> that we should leave well alone - any use of LIKE in this context is
> just about guaranteed to cause massive confusion.
Also, the semantics of LIKE are perfectly clearly specifie
On Nov 13, 2007 12:30 AM, Christopher Browne <[EMAIL PROTECTED]> wrote:
> Something I found *really* interesting was that whenever we pushed any
> "high traffic" systems onto PostgreSQL 8.1, I kept seeing measurable
> performance improvements taking place every day for a week.
>
> Evidently, it too
Greg Sabino Mullane wrote:
Ugh, in testing I see some nastiness here without any explicit
require. It looks like there's an implicit require if the text
contains certain chars.
Exactly.
Looks like it's going to be very hard, unless someone has some
brilliant insight I'm missing :-(
Trevor Talbot wrote:
On 11/13/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Am Dienstag, 13. November 2007 schrieb Gregory Stark:
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
What we'd need is a way to convert a LIKE pattern into a tsquery
('%foo%bar%' => 'foo & bar')
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Ugh, in testing I see some nastiness here without any explicit
> require. It looks like there's an implicit require if the text
> contains certain chars.
Exactly.
> Looks like it's going to be very hard, unless someone has some
> brillian
On 11/13/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 13. November 2007 schrieb Gregory Stark:
> > "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> > > What we'd need is a way to convert a LIKE pattern into a tsquery
> > > ('%foo%bar%' => 'foo & bar'). Then you might even be abl
On Tue, 2007-11-13 at 13:32 +0100, Peter Eisentraut wrote:
> Am Dienstag, 13. November 2007 schrieb Gregory Stark:
> > "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> > > What we'd need is a way to convert a LIKE pattern into a tsquery
> > > ('%foo%bar%' => 'foo & bar'). Then you might even be ab
Ron Mayer wrote:
Heikki Linnakangas wrote:
Luke Lonergan wrote:
Vacuum is a better thing to run, much less CPU usage.
Vacuum is actually not good for this purpose, because it's been
special-cased to not bump the usage count.
Though the OS's page cache will still see it as accesses, no?
Yes
Heikki Linnakangas wrote:
> Luke Lonergan wrote:
>> Vacuum is a better thing to run, much less CPU usage.
>
> Vacuum is actually not good for this purpose, because it's been
> special-cased to not bump the usage count.
Though the OS's page cache will still see it as accesses, no?
---
>>> On Tue, Nov 13, 2007 at 2:05 PM, in message
<[EMAIL PROTECTED]>, Andrew Sullivan <[EMAIL PROTECTED]>
wrote:
> On Tue, Nov 13, 2007 at 02:36:14PM -0500, Greg Smith wrote:
>
>> I see this as similar to the old optimizer hint argument, where there
>> certainly exist some edge cases where peopl
On Tue, Nov 13, 2007 at 02:36:14PM -0500, Greg Smith wrote:
> Sure, but in this case the reasoning seems sound enough.
Yes. But. . .
> I see this as similar to the old optimizer hint argument, where there
> certainly exist some edge cases where people know something the optimizer
> doesn't w
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I've just been looking at the state machine in wparser_def.c. I think
the processing for entities is also a few bob short in the pound. It
recognises decimal numeric character references, but nor hexadecimal
numeric character refe
On Tue, 13 Nov 2007, Andrew Sullivan wrote:
I have to agree with what Tom says, however, about people thinking
they're smarter than the system. Much of the time, this sort of thumb
on the scale optimisation just moves the cost to some other place
Sure, but in this case the reasoning seems so
On Tue, 13 Nov 2007, Jignesh K. Shah wrote:
I have tried increasing the bg_lru_multiplier from 2 to 5 from default but I
dont see any more writes by bgwriter happening than my previous test which
used the default.
The multiplier only impacts writes being done by the LRU eviction
mechanism; i
All,
> I'm not sure what the solution is. This scenario is going to be a problem
> for any system which tries to judge future usage based on past usage. If
> the infrequent query with a strict response time requirement is infrequent
> enough any automatic algorithm will evict it.
The way Greg put
On Tue, Nov 13, 2007 at 01:59:15PM -0500, Doug Knight wrote:
> All,
> I am having a problem loading functions from a text file into postgres
> on the Windows platform. If the source code stored in the file contains
> tabs, they get changed to \x09, which causes problems when the function
> is execu
All,
I am having a problem loading functions from a text file into postgres
on the Windows platform. If the source code stored in the file contains
tabs, they get changed to \x09, which causes problems when the function
is executed. As an example see attached, which preserves the tabs in the
origin
I am running EAStress workload.. which doesnt do manual checkpoints as
far as I know..
I will turn on checkpoint_logging to get more idea as Heikki suggested
thanks.
-Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
I am running tests with PG8.3b2 on Solaris 10 8/07
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> I am running tests with PG8.3b2 on Solaris 10 8/07 and I still see IO
> flood when checkpoint happens.
I am thinking that you are probably trying to test that by issuing
manual CHECKPOINT commands. A manual checkpoint is still done at full
speed, a
Jignesh K. Shah wrote:
I am running tests with PG8.3b2 on Solaris 10 8/07 and I still see IO
flood when checkpoint happens.
I have tried increasing the bg_lru_multiplier from 2 to 5 from default
but I dont see any more writes by bgwriter happening than my previous
test which used the default.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Why do we need assignment casts from cidr, inet, bool, and xml to
> text?
Because these cast conversion functions act differently from the datatype
output functions, eg
regression=# select true;
bool
--
t
(1 row)
regression=# select true::text;
Hello,
I am running tests with PG8.3b2 on Solaris 10 8/07 and I still see IO
flood when checkpoint happens.
I have tried increasing the bg_lru_multiplier from 2 to 5 from default
but I dont see any more writes by bgwriter happening than my previous
test which used the default.
Then I tried i
On Mon, Nov 12, 2007 at 10:54:34PM -0500, Tom Lane wrote:
> class. But if that's your problem, "pin these tables in memory" is
> still an awfully crude solution to the problem. I'd be inclined to
> think instead about a scheme that lets references made by
> higher-priority queries bump buffers'
On Mon, Nov 12, 2007 at 06:55:09PM -0800, Joshua D. Drake wrote:
> Cost is always an issue, even if implicit. If the person is so hung up
> on the idea of pushing things into ram there is a pretty good
> possibility they have priced out the 50 and 100 spindle devices needed
> to get the same typ
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> I realized this when editing the documentation but not clearly. I
> noticed that:
>
>
> http://momjian.us/main/writings/pgsql/sgml/textsearch-intro.html#TEXTSEARCH-MATCHING
>
> tsvector @@ tsquery
> tsquery @@ tsvector
> text
[EMAIL PROTECTED] wrote:
Hello
I am new to PostgreSQL.. coming off MS SQL Server.
can you please add me to your mailing lists...etc
Thank you !!
Regards,
Robert Alster
Sr. Software Engineer
Commercial Simulation
Direct: 703.234.2159
[EMAIL PROTECTED]
Are you going to be hacking on
Hello
I am new to PostgreSQL.. coming off MS SQL Server.
can you please add me to your mailing lists...etc
Thank you !!
Regards,
Robert Alster
Sr. Software Engineer
Commercial Simulation
Direct: 703.234.2159
[EMAIL PROTECTED]
postgres=# select *,(select typname from pg_type where oid = castsource) as
source,(select typname from pg_type where oid = casttarget) as target from
pg_cast where castsource = 25 or casttarget = 25;
castsource | casttarget | castfunc | castcontext | source | target
+--
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Am Dienstag, 13. November 2007 schrieb Gregory Stark:
>> "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
>> > What we'd need is a way to convert a LIKE pattern into a tsquery
>> > ('%foo%bar%' => 'foo & bar'). Then you might even be able to sneak
>>
Am Dienstag, 13. November 2007 schrieb Gregory Stark:
> "Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> > What we'd need is a way to convert a LIKE pattern into a tsquery
> > ('%foo%bar%' => 'foo & bar'). Then you might even be able to sneak
> > index-optimized text search into existing applicati
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> What we'd need is a way to convert a LIKE pattern into a tsquery ('%foo%bar%'
> => 'foo & bar'). Then you might even be able to sneak index-optimized text
> search into existing applications. Might be worth a try.
I don't think that's the righ
Am Montag, 12. November 2007 schrieb Pavel Stehule:
> > Huh, what version of the standard is this? My copy (the typical 2003
> > draft) doesn't have SQL/MM AFAICS.
>
> I found
>
> http://jtc1sc32.org/doc/N0751-0800/32N0771T.pdf
> http://www.sigmod.org/record/issues/0112/standards.pdf
> http://dbs.
Am Montag, 12. November 2007 schrieb Martijn van Oosterhout:
> On Mon, Nov 12, 2007 at 03:44:18PM -0500, Aidan Van Dyk wrote:
> > Can LIKE be easily overloaded in the parser? So:
> > text LIKE text
> > works in it's current form, and
> > tsvector LIKE tsquery
> > also works like the @@? O
Am Samstag, 10. November 2007 schrieb Bruce Momjian:
> Log Message:
> ---
> Use strip -x on OS/X-darwin because non-"-x" causes link problems:
>
> http://archives.postgresql.org/pgsql-hackers/2007-10/msg01470.php
>
> Modified Files:
> --
> pgsql/config:
> install-s
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'd be inclined to think instead about a scheme that lets references made by
> higher-priority queries bump buffers' use-counts by more than 1, or some
> other way of making the priority considerations visible to an automatic
> cache management algorithm.
Luke Lonergan wrote:
Vacuum is a better thing to run, much less CPU usage.
Vacuum is actually not good for this purpose, because it's been
special-cased to not bump the usage count.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broad
On Tue, 2007-11-13 at 08:58 +0100, Pavel Stehule wrote:
> On 13/11/2007, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > I'm thinking we can have an inlinable function
> >
> > contains(text, text) returns int
> >
> > Return values limited to just 0 or 1 or NULL, as with SQL/MM.
> > It's close to SQL/MM
42 matches
Mail list logo
