ERR ORR writes:
> 1) What is the difference between *varchar_pattern_ops* and *
> varchar_text_ops*?
None whatsoever --- they're both there just so that people can write an
opclass name that matches the declared type of their table column.
> 2) Is there any pre-definded operator class for indexe
Hi,
I actually have several questions on indexes and operator classes:
1) What is the difference between *varchar_pattern_ops* and *
varchar_text_ops*?
They both appear to work similarly and in both cases the operands are cast
to
type TEXT when I look at the explain of the query.
2) Is there any
On 16 June 2010 19:07, Bryan Montgomery wrote:
> If I do select * from Table_A a, Table_X x where a.id = x.id
> and it only returns 1 or a few rows, should it use an index if I have an
> index built on Table_A using id?
It should because it scans Table_A too.
> Or do I need an index individually
Hello,
A quick question (I think).
If I have Table_A with id integer, val text - and no data.
Table_B inherits from Table_A and has a bunch of data.
Table_C inherits from Table_A and has some data.
Table_X has id integer, someValue integer
If I do select * from Table_A a, Table_X x where a.id = x.
As I told you, I use to design indexes based upon the queries, the WHERE
clauses especially.
My fear is that in PGSQL the runtime "index composition" can be a drawback to
the performances if compared to "static index composition".
Is this true accordingly to your experience?
Is there any "best
On Tue, Sep 16, 2008 at 12:24 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 10:52 AM, regme please <[EMAIL PROTECTED]> wrote:
>> Hi all.
>> I usually create indexes accordingly to the queries used in my software.
>> This means the more often than not I have composited index
On Tue, Sep 9, 2008 at 10:52 AM, regme please <[EMAIL PROTECTED]> wrote:
> Hi all.
> I usually create indexes accordingly to the queries used in my software.
> This means the more often than not I have composited indexes over more than
> one column.
> What'd be in PGSQL (v8.3+) the pros and cons of
Any hint?
> Hi all.
> I usually create indexes accordingly to the queries used in my software.
> This means the more often than not I have composited indexes over more than
> one column.
> What'd be in PGSQL (v8.3+) the pros and cons of having instead only
> one-column indexes?
> Thanks in advance
Hi all.
I usually create indexes accordingly to the queries used in my software.
This means the more often than not I have composited indexes over more than
one column.
What'd be in PGSQL (v8.3+) the pros and cons of having instead only
one-column indexes?
Thanks in advance.
RMP.
On Mon, 15 Nov 2004 11:38:29 +0100, Stefano Bonnin
<[EMAIL PROTECTED]> wrote:
>
> Only a simple question
>
> I have a table with
>
> primarykey(field1,field2,field3)
>
> and I want to execure a query like
>
> select * from my_table where field1 = some_value
>
> if I define an index on f
Only a simple question
I have a table with
primarykey(field1,field2,field3)
and I want to execure a query like
select * from
my_table where field1 = some_value
if I define an index on field1, I increase the
query performace or not?
Thanks
> This table has no indexes at all. Each query made (using EXPLAIN) reveals a
> "Seq Scan".
> So far, everything is OK.
> Then I define 2 indexes, one affects a varchar field, for example 'lastname'
> an the other a float type field, let´s call it 'id'.
> When I perform a query such as SELECT * FR
Postgres Version : 6.5 (beta)
I have a table with 53411 rows.
This table has no indexes at all. Each query made (using EXPLAIN) reveals a
"Seq Scan".
So far, everything is OK.
Then I define 2 indexes, one affects a varchar field, for example 'lastname'
an the other a float type field, let´s call i
13 matches
Mail list logo
