Josh Berkus <[EMAIL PROTECTED]> writes:
> Nah, if it's only Niagara, it's not worth bothering.
It's not only that aspect of it --- it's that I am 100% convinced that
Magne has misidentified the source of whatever FPU contention he's
seeing. The floating-point code in s_lock() is executed only jus
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Nov 14, 2007 at 07:46:58AM +, Gregory Stark wrote:
>> Have you yet given any advantages of contains over @@ ?
> Familiarity for users of SQL Server that are migrating? ;-)
> (http://msdn2.microsoft.com/en-us/library/ms187787.aspx)
That arg
Greg,
> That says precisely nothing about the matter at hand. Someone should
> simply change it and benchmark it in pgsql. I doubt you'll see a
> difference there on regular AMD/Intel ... and if it makes the sun
> hyperthreaded cpu happier...
Nah, if it's only Niagara, it's not worth bothering.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> [ replace LIKE with this: ]
> CREATE FUNCTION textlike_ts(text, text) RETURNS boolean
> RETURNS NULL ON NULL INPUT IMMUTABLE
> LANGUAGE SQL
> AS $$ SELECT $1 @@ likepattern_to_tsquery($2) AND $1 #~~# $2; $$;
Cute trick, but as-is this wil
Gregory Maxwell wrote:
On Nov 14, 2007 10:12 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
http://www.intel.com/performance/server/xeon/intspd.htm
http://www.intel.com/performance/server/xeon/fpspeed.htm
That says precisely nothing about the matter at hand. Someone should
simply change it and
On Nov 14, 2007 10:12 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> http://www.intel.com/performance/server/xeon/intspd.htm
> http://www.intel.com/performance/server/xeon/fpspeed.htm
That says precisely nothing about the matter at hand. Someone should
simply change it and benchmark it in pgsql.
On Nov 14, 2007, at 6:57 PM, Josh Berkus wrote:
Tom,
I've got one upstairs (HPPA), and I believe that it's actually a
pretty
common situation in scientifically-oriented workstations from a few
years back.
Last I checked, scientific workstations aren't exactly a common
platform for
Post
Josh Berkus wrote:
Tom,
I've got one upstairs (HPPA), and I believe that it's actually a pretty
common situation in scientifically-oriented workstations from a few
years back.
Last I checked, scientific workstations aren't exactly a common platform for
PostgreSQL servers.
The question is,
Tom,
> I've got one upstairs (HPPA), and I believe that it's actually a pretty
> common situation in scientifically-oriented workstations from a few
> years back.
Last I checked, scientific workstations aren't exactly a common platform for
PostgreSQL servers.
The question is, for our most commo
David Fetter wrote:
> On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
> > Peter Eisentraut wrote:
> > > Letting psql execute a script file that is really a directory
> > > doesn't complain at all:
> > >
> > > $ psql -f /tmp
> > >
> > > Should we do some kind of stat() before openi
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > Letting psql execute a script file that is really a directory
> > doesn't complain at all:
> >
> > $ psql -f /tmp
> >
> > Should we do some kind of stat() before opening the file and abort
> > if it's a
On 11/14/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> I wrote:
> > 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 dont understand vacuum a lot.. I admit I am stupid :-)
When you say scanned... do you mean reads or do you mean writes?
Since its really writes that I am having trouble.. the auto vacuum
message tells me 11 pages were removed and so many tuples were
removed.. I am guessing its writes.
I c
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Wed, 14 Nov 2007, Tom Lane wrote:
>> Huh? This is just an option for the "simple" dictionary, it's got
>> nothing to do with thesaurus AFAICS.
> I can assign simple dictionary as a normalization dictionary for thesaurus
Sure. So what? You wouldn't
On Wed, Nov 14, 2007 at 10:25:23PM +0100, Peter Eisentraut wrote:
> Martijn van Oosterhout wrote:
> > To be honest I think that psql shouldn't be ignoring the
> > EISDIR error the kernel is returning.
>
> We use fopen(), which doesn't appear to pass that on.
It's not the fopen that fails, it's th
Martijn van Oosterhout wrote:
> To be honest I think that psql shouldn't be ignoring the
> EISDIR error the kernel is returning.
We use fopen(), which doesn't appear to pass that on.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> So from the PostgreSQL view things are doing fine based on outputs: I
> need to figure out the Solaris view on it now.
> Could it be related to autovacuum happening also?
Maybe ... have you tried fiddling with the vacuum_cost_delay options?
Lookin
On Thu, Sep 13, 2007 at 02:02:14PM -0700, Neil Conway wrote:
> On Fri, 2007-09-07 at 08:29 -0500, Kenneth Marshall wrote:
> > This is a great starting point. I would appreciate it if you have the
> > time and could make it apply cleanly to HEAD.
>
> Just to give you an update on this, I'll try to
I was waiting to digest what I saw before sending it to the group
I am running EAStress workload
I am using odata_sync which should sync as soon as it is written
with checkpoint_completion_target=0.9 and checkpoint_time=5m it seems to
be doing the right thing from the logfile output
2007-
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory doesn't complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, r
On 11/14/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> The other problem with using modulo is that it makes the result depend
> mostly on the low-order bits of the random() result, rather than mostly
> on the high-order bits; with lower-grade implementations of random(),
> the lower bits are materiall
On Wed, 14 Nov 2007, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Yes, this the same problem we had months ago trying to improve the
syntax, that there was no easy syntax that covered all common use cases.
The thing that we keep coming up against is that we'd like queries to
be a
Letting psql execute a script file that is really a directory doesn't complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, this the same problem we had months ago trying to improve the
> syntax, that there was no easy syntax that covered all common use cases.
The thing that we keep coming up against is that we'd like queries to
be able to depend on default_text_search_c
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Better idea:
>
> > create function
> > contains(sourceText text, searchText text, config text) returns boolean
> > as $$
> > to_tsvector(config, sourceText) @@ to_tsquery(config, searchText);
> > $$ language sql;
>
> I think you have c
Simon Riggs <[EMAIL PROTECTED]> writes:
> Better idea:
> create function
> contains(sourceText text, searchText text, config text) returns boolean
> as $$
> to_tsvector(config, sourceText) @@ to_tsquery(config, searchText);
> $$ language sql;
I think you have confused "simple query syntax" with "
On Wed, Nov 14, 2007 at 09:33:17PM +0100, Zdenek Kotala wrote:
> >Sure, why not. To be honest I think that psql shouldn't be ignoring the
> >EISDIR error the kernel is returning.
>
> But it works when you open directory in read-only mode. See posix
> definition:
>
> [EISDIR]
> The named file
I wrote:
> 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.
Here is how this could work:
CREATE FUNCTION likepattern_to_tsquery(
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Letting psql execute a script file that is really a directory doesn't complain
at all:
$ psql -f /tmp
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right? (Do
Martijn van Oosterhout wrote:
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
Should we do some kind of stat() before opening the file and abort if it's a
directory?
Actually anything other than a plain file, right? (Do we really want to
be able to psql -f a_pipe?)
Sure, why
On Wed, Nov 14, 2007 at 05:15:20PM -0300, Alvaro Herrera wrote:
> > Should we do some kind of stat() before opening the file and abort if it's
> > a
> > directory?
>
> Actually anything other than a plain file, right? (Do we really want to
> be able to psql -f a_pipe?)
Sure, why not. To be hon
Peter Eisentraut wrote:
> Letting psql execute a script file that is really a directory doesn't
> complain
> at all:
>
> $ psql -f /tmp
>
> Should we do some kind of stat() before opening the file and abort if it's a
> directory?
Actually anything other than a plain file, right? (Do we reall
On Wed, 14 Nov 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
On Wed, 14 Nov 2007, Tom Lane wrote:
Huh? This is just an option for the "simple" dictionary, it's got
nothing to do with thesaurus AFAICS.
I can assign simple dictionary as a normalization dictionary for thesau
On Wed, 14 Nov 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
On Wed, 14 Nov 2007, Tom Lane wrote:
One thought that came to mind is that the option name should be just
"Accept" not "AcceptAll". To me "All" implies that it would accept
*everything* ... including stopwords.
As I understand it*, the situation here is:
1. Client support in pgadmin
2. Support in the Windows installer (optional?)
3. Not in /contrib
Now, I realise "it's too late for 8.3" is a bloody good argument, but
I'm curious as to whether packagers on other platforms are planning.
Traditionally I
On Wed, 14 Nov 2007, Mark Mielke wrote:
The other problem with using modulo is that it makes the result depend
mostly on the low-order bits of the random() result, rather than mostly
on the high-order bits; with lower-grade implementations of random(),
the lower bits are materially less random t
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Wed, 14 Nov 2007, Tom Lane wrote:
>> One thought that came to mind is that the option name should be just
>> "Accept" not "AcceptAll". To me "All" implies that it would accept
>> *everything* ... including stopwords.
> wait, I remind the problem with
On Wed, 14 Nov 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
Let's consider one example - removing accents.
In the past I always recommend people to use regex functions before
to_tsvector conversion to remove accents, but recently I was noticed that
such trick doesn't work wit
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Let's consider one example - removing accents.
> In the past I always recommend people to use regex functions before
> to_tsvector conversion to remove accents, but recently I was noticed that
> such trick doesn't work with headline(). So, the only way is
In principle the right way is to allow any dictionary have option
like 'PassThrough' and internal function get_dict_options(dict, option)
to check if PassThrough option is true.
Let's consider one example - removing accents.
In the past I always recommend people to use regex functions before
to_
Tom Lane wrote:
> This patch:
> http://archives.postgresql.org/pgsql-patches/2007-11/msg00137.php
> seems simple and useful enough that I think we ought to slip it into
> 8.3, even though we are far past feature freeze.
>
> As the "simple" dictionary type stands in CVS HEAD, it is only useful as
>
This patch:
http://archives.postgresql.org/pgsql-patches/2007-11/msg00137.php
seems simple and useful enough that I think we ought to slip it into
8.3, even though we are far past feature freeze.
As the "simple" dictionary type stands in CVS HEAD, it is only useful as
the last dictionary in a stac
Mark Mielke <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My goodness that's a hardware-dependent proposal. Shall we discuss
>> how many CPUs there are where an integer division is *slower* than
>> a floating-point op?
> Do you have one in mind, or is this a straw man? :-)
I've got one upstai
Tom Lane wrote:
=?ISO-8859-1?Q?Magne_M=E6hre?= <[EMAIL PROTECTED]> writes:
I understand the reasoning for the backoff (as of the discussion on
2003-08-05), but is there any particular reason for using floating
point operations here ? Maybe a modulo would be just as good (or
better since it
=?ISO-8859-1?Q?Magne_M=E6hre?= <[EMAIL PROTECTED]> writes:
> I understand the reasoning for the backoff (as of the discussion on
> 2003-08-05), but is there any particular reason for using floating
> point operations here ? Maybe a modulo would be just as good (or
> better since it doesn't involv
Simon Riggs wrote:
> Better idea:
>
> in-linable function called
>
> create function
> contains(sourceText text, searchText text, config text) returns boolean
> as $$
> to_tsvector(config, sourceText) @@ to_tsquery(config, searchText);
> $$ language sql;
>
> so that
>
> SELECT title
> FROM pgw
Kevin Grittner wrote:
> > . . .the abuse of such hints in applications I have seen is so
rampant as to
> > make me doubt the utility of adding them anyway. It's true that by
adding
> > hints, you give a facility to a good, competent designer who has a
really
> I have trouble not seeing the point
Magne Mæhre wrote:
I was playing with a Nevada server and noticed a rush on the FPU
(the Nevada has a single shared FPU for its 32 threads).
Probably you mean Niagara ;-).
Zdenek
---(end of broadcast)---
TIP 1: if posting/readi
I was playing with a Nevada server and noticed a rush on the FPU
(the Nevada has a single shared FPU for its 32 threads).
Looking at the spinlock code, I found :
cur_delay += (int) (cur_delay *
((double) random() / (double) MAX_RANDOM_VALUE) + 0.5);
I understand the reasoning for the
"Jignesh K. Shah" <[EMAIL PROTECTED]> wrote:
> I am running tests with PG8.3b2 on Solaris 10 8/07 and I still see IO
> flood when checkpoint happens.
Are there any i/o tuning knobs in Solaris? LDC in 8.3 expects writing
activity in kernel is strong enough to keep dirty pages in kernel
in a smal
On Wed, Nov 14, 2007 at 07:46:58AM +, Gregory Stark wrote:
> "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 conta
51 matches
Mail list logo
