Is there any indexing technique available I can use when joining tables
with a regular expression pattern in pgsql?
I know one method for indexing strings that will be matched with regular
expression patterns, and that is using so called k-gram indexes.
Indexing the string "kjartan" with k-gram i
On Sun, 7 Apr 2002, [ISO-8859-1] Kjartan Ásþórsson wrote:
> Is there any indexing technique available I can use when joining tables
> with a regular expression pattern in pgsql?
>
> I know one method for indexing strings that will be matched with regular
> expression patterns, and that is using s
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Fernando Nasser <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne wrote:
> >> You know, I'm kinda surprised that the spec doesn't define a
> CURRENT_SCHEMA
> >> variable you can query???
>
> > Maybe because it would
Thank you for your reply.
No, I am not looking for a fuzzy match. I am simply wondering if there
are some methods available that can speed up joining of tables when
the join is done with a regular expression operator (one table
contains regular expression patterns, and the other strings that
shou
On Fri, 5 Apr 2002, Barry Lind wrote:
> Af far as I know Oracle doesn't have any short cut (along the lines of
> what is being discussed in this thread) for this operation. However
> Oracle is more efficient in providing the answer than postgres currently
> is. While postgres needs to perfor
Tom Lane wrote:
>
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > "Dann Corbit" <[EMAIL PROTECTED]> writes:
> >> It would be nice if total table cardinality could be maintained live.
>
> > How would this work with MVCC?
>
> It wouldn't. That's why it's not there. Under MVCC, table cardinality
Tatsuo Ishii wrote:
> BTW, for the 7.2.x tree we need a solution with lesser impact.
> For this purpose, I would like to change PQescapeBytea as I stated in
> the previous mail. Objection?
> --
> Tatsuo Ishii
No objection here, but can we wrap the change in #ifdef MULTIBYTE so
there's no effect
Joe Conway <[EMAIL PROTECTED]> writes:
> No objection here, but can we wrap the change in #ifdef MULTIBYTE so
> there's no effect for people who don't use MULTIBYTE?
That opens up the standard set of issues about "what if your server is
MULTIBYTE but your libpq is not?" It seems risky to me.
On Sun, 7 Apr 2002 13:49:08 +0200
"Kjartan " <[EMAIL PROTECTED]> wrote:
> Thank you for your reply.
>
> No, I am not looking for a fuzzy match. I am simply wondering if there
> are some methods available that can speed up joining of tables when
> the join is done with a regular expression operato
> > > Probably I'm misunderstanding this thread.
> > > Why must the query_timeout be reset particularly ?
> > > What's wrong with simply issueing set query_timeout
> > > command just before every query ?
> >
> > You could do that, but we also imagine cases where people would want to
> > set a tim
> > I guess it's a matter of definition: Do you consider SET variables
> > database state or session metadata? I think some are this and some are
> > that. I'm not sure how to draw the line, but throwing everything from one
> > category into the other isn't my favorite solution.
>
> You seem to
I am not sure about the idea of -g by default. I know lyx uses -g by
default, and the compile/install takes forever. In fact, I have removed
-g from my compiles here because it takes too long to compile/link and I
do it too often. When I need to debug, I recompile with -g. My concern
is that w
Hello:
Not sure of where to post this, it's not a bug, more of an
application note.. Using linux and iptables as a firewall, requests for
services are redirected to the machines providing those services, including
postgress. This approach has been in place for over a year, and includes
Bruce Momjian wrote:
>
> > > > Probably I'm misunderstanding this thread.
> > > > Why must the query_timeout be reset particularly ?
> > > > What's wrong with simply issueing set query_timeout
> > > > command just before every query ?
> > >
> > > You could do that, but we also imagine cases where
> > > Sorry I couldn't understand your point.
> > > It seems the simplest and the most certain way is to call
> > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > RESET at all. Is the overhead an issue ?
> >
> > What about psql and libpq. Doing a timeout before every query is a
> >
Bruce Momjian wrote:
>
> > > I guess it's a matter of definition: Do you consider SET variables
> > > database state or session metadata? I think some are this and some are
> > > that. I'm not sure how to draw the line, but throwing everything from one
> > > category into the other isn't my favo
Bruce Momjian wrote:
>
> > > > Sorry I couldn't understand your point.
> > > > It seems the simplest and the most certain way is to call
> > > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > > RESET at all. Is the overhead an issue ?
> > >
> > > What about psql and libpq. Doing a t
Kenny H Klatt writes:
> Inital testing worked well. When it was decided to have applications
> normally directed at production try the development instance, ident
> authenication failed. All other tests passed, including hostssl
> connections. When the firewall redirects traffic to it
> > Af far as I know Oracle doesn't have any short cut (along the lines of
> > what is being discussed in this thread) for this operation. However
> > Oracle is more efficient in providing the answer than postgres
> currently
> > is. While postgres needs to perform a full scan on the table, Orac
> That seems like pure speculation to me, if not outright wrong. If we
> can't renumber the attnums it'll be because the table's tuples still
> have data at a particular column position. Since we'll need to know
> the datatype of that data (if only to skip over it correctly), there
> will still
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > I guess it's a matter of definition: Do you consider SET variables
> > > > database state or session metadata? I think some are this and some are
> > > > that. I'm not sure how to draw the line, but throwing everything from one
> > > > cat
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > > Sorry I couldn't understand your point.
> > > > > It seems the simplest and the most certain way is to call
> > > > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > > > RESET at all. Is the overhead an issue ?
> > > >
> > > >
Christopher Kings-Lynne wrote:
> > > Af far as I know Oracle doesn't have any short cut (along the lines of
> > > what is being discussed in this thread) for this operation. However
> > > Oracle is more efficient in providing the answer than postgres
> > currently
> > > is. While postgres needs
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> You know there is a way to do this and not break client compatibility.
> Rename the current pg_attribute relation to pg_baseatt or something. Fix
> all references to it in the code. Create a system view called pg_attribute
> which is SELECT
> Joe Conway <[EMAIL PROTECTED]> writes:
> > No objection here, but can we wrap the change in #ifdef MULTIBYTE so
> > there's no effect for people who don't use MULTIBYTE?
>
> That opens up the standard set of issues about "what if your server is
> MULTIBYTE but your libpq is not?" It seems ris
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I guess it's a matter of definition: Do you consider SET variablesdatabase state or session metadata? I think some are this and some arethat. I'm not sure how to draw the line, but throwing
26 matches
Mail list logo
