Hi Peter,
Many thanks for your response. I tried to cancel the thread, it was
unfortunately stupidity that was the issue. We'd been forced to manually
analyze our tables due to time constraints, and one of the table partitions
read in the query was missed. It was reporting a bitmap index scan o
On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
> Hi,
>
> We have recently promoted our Prod DB slave (2TB) to migrate to new
> hardware, and upgraded from v9.2.9.21 to 9.5.1.6 using pg_upgrade.
>
>
> The upgrade went without incident and we have been running for a week, but
> the optimizer
On Wed, Jul 26, 2017 at 2:05 PM, Peter Geoghegan wrote:
> On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
>> We've added duplicate indexes and analyzing, however the new indexes are
>> still ignored unless we force using enable_seqscan=no or reduce
>> random_page_cost to 2. The query respon
On Tue, Jul 25, 2017 at 10:34 PM, Nick Brennan wrote:
> We've added duplicate indexes and analyzing, however the new indexes are
> still ignored unless we force using enable_seqscan=no or reduce
> random_page_cost to 2. The query response times using the new indexes are
> still as slow when we do
Hi,
We have recently promoted our Prod DB slave (2TB) to migrate to new
hardware, and upgraded from v9.2.9.21 to 9.5.1.6 using pg_upgrade.
The upgrade went without incident and we have been running for a week, but
the optimizer is ignoring indexes on 2 of our largest partitioned tables
causing v
On Sun, Feb 19, 2017 at 8:52 AM, Rakesh Kumar
wrote:
>
> https://www.youtube.com/watch?v=8mKpfutwD0U&t=1741s
>
> Somewhere around 13th minute, Chris Tavers mentions this:
>
> 1 - In the queuing table, the application deletes lot of rows (typical for
> a queuing table).
> 2 - Query trying to find
https://www.youtube.com/watch?v=8mKpfutwD0U&t=1741s
Somewhere around 13th minute, Chris Tavers mentions this:
1 - In the queuing table, the application deletes lot of rows (typical for a
queuing table).
2 - Query trying to find out rows to be picked by the queue, accesses them via
indexes.
3 -
Hi
2016-12-27 19:05 GMT+01:00 Арсен Арутюнян :
> Hello.
>
> I have a few questions:
>
> 1) JobStatusTest1 function has only one request and JobStatusTest2
> function has as many as six requests.
>
> Why function JobStatusTest2 is faster?
>
>
> JobStatusTest1 : 981.596 ms
>
> JobStatusTest2 : 849
Hello.
I have a few questions:
1) JobStatusTest1 function has only one request and JobStatusTest2 function
has as many as six requests.
Why function JobStatusTest2 is faster?
JobStatusTest1 : 981.596 ms
JobStatusTest2 : 849.133 ms
2) Two functions JobStatusTest3 and JobStatusTest4 perform the
Hello.
I have a few questions:
1) JobStatusTest1 function has only one request and JobStatusTest2 function
has as many as six requests.
Why function JobStatusTest2 is faster?
JobStatusTest1 : 981.596 ms
JobStatusTest2 : 849.133 ms
2) Two functions JobStatusTest3 and JobStatusTest4 perform the
I've got a SaaS situation where I'm using 1000+ schemas in a single
database (each schema contains the same tables, just different data
per tenant). I used schemas so that the shared app servers could
share a connection to the single database for all schemas. Things are
working fine. However, whe
On 20.1.2012 19:47, Matt Dew wrote:
> On 01/13/2012 02:49 PM, Tomas Vondra wrote:
>> On 13.1.2012 22:20, Tom Lane wrote:
>>> Matt Dew writes:
An interesting sidenote we realized. the nice system shutdown script
/etc/init.d/postgres doesn't actually wait for the db to be down, it
ju
On 01/13/2012 02:49 PM, Tomas Vondra wrote:
On 13.1.2012 22:20, Tom Lane wrote:
Matt Dew writes:
An interesting sidenote we realized. the nice system shutdown script
/etc/init.d/postgres doesn't actually wait for the db to be down, it
just waits for pg_ctl to return.
By default, "pg_ctl sto
On 13.1.2012 22:20, Tom Lane wrote:
> Matt Dew writes:
>> An interesting sidenote we realized. the nice system shutdown script
>> /etc/init.d/postgres doesn't actually wait for the db to be down, it
>> just waits for pg_ctl to return.
>
> By default, "pg_ctl stop" does wait for the server to s
Matt Dew writes:
> An interesting sidenote we realized. the nice system shutdown script
> /etc/init.d/postgres doesn't actually wait for the db to be down, it
> just waits for pg_ctl to return.
By default, "pg_ctl stop" does wait for the server to shut down ...
regards
On 01/12/2012 01:21 PM, Tom Lane wrote:
Matt Dew writes:
On 01/11/2012 04:29 PM, Tom Lane wrote:
What exactly is your definition of a "clean shutdown"?
Is a reboot command considered a clean shutdown? It's a redhat box
which called /etc/init.d/postgresql stop, which does: pg_ctl stop -D
'$P
On 01/12/2012 01:21 PM, Tom Lane wrote:
Matt Dew writes:
On 01/11/2012 04:29 PM, Tom Lane wrote:
What exactly is your definition of a "clean shutdown"?
Is a reboot command considered a clean shutdown? It's a redhat box
which called /etc/init.d/postgresql stop, which does: pg_ctl stop -D
'$P
Matt Dew writes:
> On 01/11/2012 04:29 PM, Tom Lane wrote:
>> What exactly is your definition of a "clean shutdown"?
> Is a reboot command considered a clean shutdown? It's a redhat box
> which called /etc/init.d/postgresql stop, which does: pg_ctl stop -D
> '$PGDATA' -s -m fast
Well, a fast
On 01/11/2012 04:29 PM, Tom Lane wrote:
Matt Dew writes:
I have a database that was shut down, cleanly, during an 'reindex
table' command. When the database came back up, queries against that
table started doing sequential scans instead of using the indexes as
they had been up until that
Matt Dew writes:
> I have a database that was shut down, cleanly, during an 'reindex
> table' command. When the database came back up, queries against that
> table started doing sequential scans instead of using the indexes as
> they had been up until that point.
What exactly is your def
On 01/11/2012 11:07 AM, Scott Marlowe wrote:
On Wed, Jan 11, 2012 at 10:42 AM, Matt Dew wrote:
Hello all,
I have a database that was shut down, cleanly, during an 'reindex table'
command. When the database came back up, queries against that table
started doing sequential scans instead of
On Wed, Jan 11, 2012 at 10:42 AM, Matt Dew wrote:
> Hello all,
> I have a database that was shut down, cleanly, during an 'reindex table'
> command. When the database came back up, queries against that table
> started doing sequential scans instead of using the indexes as they had been
> up un
Hello all,
I have a database that was shut down, cleanly, during an 'reindex
table' command. When the database came back up, queries against that
table started doing sequential scans instead of using the indexes as
they had been up until that point.
We tried:
1) vacuuming the table (vacu
On Sunday, December 18, 2011 04:00:14 PM amit sehas wrote:
> Yes i was trying to determine how to make a View work in this situation.
> From reading the details on PostgreSQL Views are not persistent, ie they
> are just a SQL query short hand rather than actually creating any physical
> entity back
hone From: amit sehas
Sent: 19 December 2011 06:17
To: pgsql-general@postgresql.org; David Johnston
Subject: Re: [GENERAL] indexes and tables
Yes i was trying to determine how to make a View work in this situation.
From reading the details on PostgreSQL Views are not persistent, ie they
are just
inheritance works in POstgres...
any help is greatly appreciated...
thanks
--- On Sun, 12/18/11, David Johnston wrote:
> From: David Johnston
> Subject: RE: [GENERAL] indexes and tables
> To: "'amit sehas'" , pgsql-general@postgresql.org
> Date: Sunday, December 1
to deal with multiple
views/queries.
David J.
-Original Message-
From: amit sehas [mailto:cu...@yahoo.com]
Sent: Sunday, December 18, 2011 7:00 PM
To: pgsql-general@postgresql.org; David Johnston
Subject: RE: [GENERAL] indexes and tables
Yes i was trying to determine how to make a View work in
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of amit sehas
Sent: Thursday, December 15, 2011 9:22 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] indexes and tables
HI,
we have a schema related question. We have
HI,
we have a schema related question. We have 10 types of resource records.
Each one of these resource records has 3 fields (attributes) (lets say f1, f2,
f3)...these fields have similar meaning to the corresponding 3 fields
in each resource record although they be named slightly differently in
Craig Ringer, 17.09.2011 02:28:
On 09/17/2011 05:47 AM, Stefan Keller wrote:
A (read-only) view should behave like a table, right?
CREATE INDEX t1_idx ON t1 (rem);
ERROR: »v1« not a table
SQL state: 42809
=> Why should'nt it be possible to create indexes on views in PG?
It's not so much th
Hi Craig,
Thank you for the explanations.
2011/9/17 Craig Ringer :
> It sounds like they probably use a materialized view, possibly stored as an
> index-oriented table. That'd be a cool thing to support, but if done that
> way would require TWO new major features PostgreSQL doesn't have.
Just to
On 09/17/2011 05:47 AM, Stefan Keller wrote:
A (read-only) view should behave like a table, right?
CREATE INDEX t1_idx ON t1 (rem);
ERROR: »v1« not a table
SQL state: 42809
=> Why should'nt it be possible to create indexes on views in PG?
It's not so much that it's not allowed, as that it'
On Fri, Sep 16, 2011 at 4:47 PM, Stefan Keller wrote:
> A (read-only) view should behave like a table, right?
>
>> CREATE INDEX t1_idx ON t1 (rem);
> ERROR: »v1« not a table
> SQL state: 42809
>
> => Why should'nt it be possible to create indexes on views in PG?
>
> An index on a view can speed up
A (read-only) view should behave like a table, right?
> CREATE INDEX t1_idx ON t1 (rem);
ERROR: »v1« not a table
SQL state: 42809
=> Why should'nt it be possible to create indexes on views in PG?
An index on a view can speed up access to the tuples underlying. And
"indexed views" could be a meth
2011/8/24 Ondrej Ivanič
> Hi,
>
> On 25 August 2011 11:17, Toby Corkindale
> wrote:
> > Do I need to make sure I re-create every index on every child table I
> > create?
> > That would be.. annoying, at best.
>
> Yes, it is little bit annoying but I like it. You don't need any index
> on parent
Hi,
On 25 August 2011 11:17, Toby Corkindale
wrote:
> Do I need to make sure I re-create every index on every child table I
> create?
> That would be.. annoying, at best.
Yes, it is little bit annoying but I like it. You don't need any index
on parent table but you have to create them "manually"
On 25/08/11 12:10, Shoaib Mir wrote:
On Thu, Aug 25, 2011 at 11:57 AM, Toby Corkindale
mailto:toby.corkind...@strategicdata.com.au>> wrote:
It seems messy to inherit the columns but not the indexes or checks
upon them :(
Yes it can be a bit annoying at timse but you can try to automa
On Thu, Aug 25, 2011 at 11:57 AM, Toby Corkindale <
toby.corkind...@strategicdata.com.au> wrote:
>
> It seems messy to inherit the columns but not the indexes or checks upon
> them :(
>
>
>
Yes it can be a bit annoying at timse but you can try to automate the whole
process as well. Like I found th
On 25/08/11 11:34, Shoaib Mir wrote:
On Thu, Aug 25, 2011 at 11:17 AM, Toby Corkindale
mailto:toby.corkind...@strategicdata.com.au>> wrote:
Do I need to make sure I re-create every index on every child table
I create?
That would be.. annoying, at best.
Is there a way to enable
On Thu, Aug 25, 2011 at 11:17 AM, Toby Corkindale <
toby.corkind...@strategicdata.com.au> wrote:
>
> Do I need to make sure I re-create every index on every child table I
> create?
> That would be.. annoying, at best.
>
> Is there a way to enable inheritance of indexes too?
>
>
You do not need an
Hi,
I'm using Pg 9.0 and inheritance to do table partitioning.
A simple example would be:
CREATE TABLE foo (
id INTEGER PRIMARY KEY,
thing VARCHAR(32)
);
CREATE INDEX foo_thing_idx ON foo(thing);
CREATE TABLE foo_1 () INHERITS (foo);
I read that foreign key constraints wouldn't be inherited
"Apparently (after reading the documentation link provided by Tom) there can
be value to indexes when accessed with leading columns missing".
That is a new one on me too - interesting.
I suppose it comes down to testing at the end of the day - if you "set
enable_seqscan to false" and "EXPLAIN ANA
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Dann Corbit
Sent: Monday, November 15, 2010 12:21 PM
To: 'Dan Halbert'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Indexes on individual columns of composite primary key
From: pgs
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Dan Halbert
Sent: Monday, November 15, 2010 12:01 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Indexes on individual columns of composite primary key
I have a table with four columns
Dan,
It depends on your application. There is no point in creating an index with
the same 3 columns in the primary key (in the same order).
If you have an index on COL1, COL2 and COL3 (in that order) then if you have
a query such as SELECT COL1, COL2, COL3 from T1 then the index will be
consider
"Dan Halbert" writes:
> I have a table with four columns. Three of those columns are defined
> as the composite primary key. Does it make sense to create indexes on
> any or all of those three columns individually for performance
> reasons?
Please see
http://www.postgresql.org/docs/9.0/static/ind
I have a table with four columns. Three of those columns are defined as the
composite primary key. Does it make sense to create indexes on any or all of
those three columns individually for performance reasons? PG does let me create
the indexes. But perhaps it's redundant, since there's an impl
On 1/27/2010 7:32 AM, J Scanf wrote:
Hi all. I have a problem with two tables of same structure:
'orders_stat_pre' and 'orders_stat_pre_new'.
store=# \d orders_stat_pre
Column | Type | Modifiers
++---
id
Hi all. I have a problem with two tables of same structure:
'orders_stat_pre' and 'orders_stat_pre_new'.
store=# \d orders_stat_pre
Column | Type | Modifiers
++---
id | integer| not n
Hi Kevin,
From the PG documentation (section 5.8 - inheritance):
http://www.postgresql.org/docs/current/static/ddl-inherit.html
"A serious limitation of the inheritance feature is that indexes (including
unique constraints) and foreign key constraints only apply to single tables,
not to their
Hi all;
where's the best place for the indexes/constraints on a partitioned table.
I assume it's best to place the FK constraints/triggers on the base/master
table and the indexes on the individual partition tables.
Thoughts?
Thanks in advance.
--
Sent via pgsql-general mailing list (pgsql-g
ruth'
See the movie - 'Syriana'
--- On Sun, 7/12/09, Brent Wood wrote:
> From: Brent Wood
> Subject: Re: [GENERAL] indexes on float8 vs integer
> To: gear...@sbcglobal.net
> Date: Sunday, July 12, 2009, 9:10 PM
> You might look at UMN mapserver or
> Geoserver to p
store the first data.
Dennis Gearon
--- On Sun, 7/12/09, Brent Wood wrote:
> From: Brent Wood
> Subject: Re: [GENERAL] indexes on float8 vs integer
> To: gear...@sbcglobal.net
> Cc: pgsql-general@postgresql.org
> Date: Sunday, July 12, 2009, 1:52 PM
> Hi Dennis,
>
> Is t
Hi Dennis,
Is there any reason you are not using PostGIS to store the values as point
geometries & use a spatial (GIST) index on them? I have tables with hundreds of
millions of point features which work well. On disk data volume is not really
worth optimising for with such systems, i suggest f
On Sat, Jul 11, 2009 at 10:15 PM, Dennis Gearon wrote:
>
> Anyone got any insight or experience in the speed and size of indexes on
> Integer(4 byte) vs float (8byte). For a project that I'm on, I'm
> contemplating using an integer for:
>
> Latitude
> Longitude
>
> In a huge, publically s
Anyone got any insight or experience in the speed and size of indexes on
Integer(4 byte) vs float (8byte). For a project that I'm on, I'm contemplating
using an integer for:
Latitude
Longitude
In a huge, publically searchable table.
In the INSERTS, the representation would be equal
Maxim Boguk <[EMAIL PROTECTED]> writes:
> But why? NULL's have some special representation in index which don't work
> same as normal values?
In general, NULLs don't work the same as normal values, no.
The reason this particular query isn't working as you are expecting is
that "foo IS NULL" isn'
Alvaro Herrera wrote:
Maxim Boguk wrote:
Sorry with all my respect to you, you look like wrong.
The difference is that the plan with -1 does not need to sort the
output, because it comes sorted out of the index; so the execution can
be stopped as soon as 5 tuples have come out. With NULL, tha
Maxim Boguk wrote:
> Sorry with all my respect to you, you look like wrong.
The difference is that the plan with -1 does not need to sort the
output, because it comes sorted out of the index; so the execution can
be stopped as soon as 5 tuples have come out. With NULL, that can't be
done.
--
Al
Sorry with all my respect to you, you look like wrong.
Here example:
With NULL's:
mboguk_billing=# EXPLAIN ANALYZE SELECT * from cluster_weight where
cluster_weight.rubric_id IS NULL ORDER BY pos LIMIT 5;
QUERY PLAN
--
Maxim Boguk <[EMAIL PROTECTED]> writes:
> Looks like when indexed search over NULL's added, planner wasn't learned
> right way use such index on "where something is NULL order by ... limit ..."
> queries.
There's nothing wrong with the plan; you've just got too many NULLs to
make it worth using
When i read about 8.3 support indexed queries on NULL values (like rubric_id is
NULL) i was really happy.
But reality strike again... look like NULL in WHERE don't allow effective using
index on (rubric_id, pos) for queries like:
... WHERE rubric_id IS NULL ORDER BY pos LIMIT 5
Here is some de
Matthew Dennis wrote:
Given table T(c1 int) and function F(arg int) create an index on T using
F(c1). It appears that if you execute "create or replace function F"
and provide a different implementation that the index still contains the
results from the original implementation, thus if you exe
On Thu, Aug 28, 2008 at 7:45 PM, Matthew Dennis <[EMAIL PROTECTED]> wrote:
> Another question though. Since I could potentially start transaction, drop
> indexes/checks, replace function, create indexes/checks, commit tranasaction
> could I deal with the case of the constant folding into the cach
Matthew Dennis wrote:
> The cases about taking a string and sending it via execute don't seem to fit
> here for 1) cases where it is impossible to track the dependencies can be
> trivially constructed and 2) the very nature of the execute statement makes
> it obvious that it I shouldn't expect it
On Thu, Aug 28, 2008 at 8:51 PM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:
> There's no way at all in the general case (a function name could be
> passed as a parameter, for example). I think Matthew is suggesting to
> track dependencies at run time, but that seems a recipe for burnt
> fingers and
On Aug 28, 2008, at 7:22 PM, Matthew Dennis wrote:
Yes, but in the case of pluggable languages, you still load
something that constitutes the "source". In the case of PL/Java,
the jar for example.
This would mean that, for example, if you changed any single function
(no matter how distan
On Thu, Aug 28, 2008 at 9:09 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 2008, at 7:04 PM, Matthew Dennis wrote:
>
>> The plpgsql execute statement, as I understand it, means "take this string
>> and execute like a client sent it to you".
>>
>
> Of course, the string could come from a
On Thu, Aug 28, 2008 at 9:01 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 2008, at 6:51 PM, Alvaro Herrera wrote:
>
>> Also, you have to keep in mind that we support pluggable languages. The
>> function's source code is just an opaque string.
>>
>
> Oh, ouch, right.
>
> I think that t
On Aug 28, 2008, at 7:04 PM, Matthew Dennis wrote:
The plpgsql execute statement, as I understand it, means "take this
string and execute like a client sent it to you".
Of course, the string could come from anywhere. There's no inherent
reason that I can think of (except good taste) that yo
On Thu, Aug 28, 2008 at 8:15 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 2008, at 6:10 PM, Matthew Dennis wrote:
>
>> I'm not sure I follow. Couldn't you track which statements were prepared
>> that called a function and either reprepare (just like reindex, recheck,
>> etc) or in the
On Aug 28, 2008, at 6:51 PM, Alvaro Herrera wrote:
Also, you have to keep in mind that we support pluggable
languages. The
function's source code is just an opaque string.
Oh, ouch, right.
I think that this is one of those cases where it's better that we
simply advertise: BE AWARE OF THI
Christophe wrote:
>
> On Aug 28, 2008, at 6:10 PM, Matthew Dennis wrote:
>> I'm not sure I follow. Couldn't you track which statements were
>> prepared that called a function and either reprepare (just like
>> reindex, recheck, etc) or in the case of dropping a function, refuse to
>> drop it
On Aug 28, 2008, at 6:10 PM, Matthew Dennis wrote:
I'm not sure I follow. Couldn't you track which statements were
prepared that called a function and either reprepare (just like
reindex, recheck, etc) or in the case of dropping a function,
refuse to drop it because something depends on it
On Thu, Aug 28, 2008 at 7:52 PM, Christophe <[EMAIL PROTECTED]> wrote:
>
> On Aug 28, 2008, at 5:49 PM, Matthew Dennis wrote:
>
>> Yes, I can see that would indeed be a problem. Are there future plans to
>> start tracking such dependencies? It seems like it would be a good idea in
>> general.
>>
On Aug 28, 2008, at 5:49 PM, Matthew Dennis wrote:
Yes, I can see that would indeed be a problem. Are there future
plans to start tracking such dependencies? It seems like it would
be a good idea in general.
I believe the EXECUTE statement would thwart such plans.
--
Sent via pgsql-gener
On Thu, Aug 28, 2008 at 5:32 PM, Christophe <[EMAIL PROTECTED]> wrote:
> On Aug 28, 2008, at 3:21 PM, Matthew Dennis wrote:
>
>> I have no doubt that someone would complain about it, but I think it's
>> better than the alternative.
>>
>
> Determining if changing any function will cause an index to
On Thu, Aug 28, 2008 at 6:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Matthew Dennis" <[EMAIL PROTECTED]> writes:
> > On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> (Changing the behavior of an allegedly IMMUTABLE function has a number
> >> of other pitfalls besides th
"Matthew Dennis" <[EMAIL PROTECTED]> writes:
> On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> (Changing the behavior of an allegedly IMMUTABLE function has a number
>> of other pitfalls besides that one, btw.)
> I'm interested in knowing what they are - could you point me
On Aug 28, 2008, at 3:21 PM, Matthew Dennis wrote:
I have no doubt that someone would complain about it, but I think
it's better than the alternative.
Determining if changing any function will cause an index to break is
not a straight-forward problem. I don't believe that PG right now
kee
On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> (Changing the behavior of an allegedly IMMUTABLE function has a number
> of other pitfalls besides that one, btw.)
>
I'm interested in knowing what they are - could you point me in the right
direction (I've read the docs on im
On Thu, Aug 28, 2008 at 9:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> If it did that, you (or someone) would complain about the enormous
> overhead imposed on trivial updates of the function. Since determining
> whether the function actually did change behavior is Turing-complete,
> we can't rea
Tom Lane <[EMAIL PROTECTED]> writes:
> Since determining whether the function actually did change behavior is
> Turing-complete, we can't realistically try to determine that in software.
> So we leave it up to the user to reindex if he makes a behavioral change in
> an indexed function.
Another
"Matthew Dennis" <[EMAIL PROTECTED]> writes:
> Given table T(c1 int) and function F(arg int) create an index on T using
> F(c1). It appears that if you execute "create or replace function F" and
> provide a different implementation that the index still contains the results
> from the original impl
Given table T(c1 int) and function F(arg int) create an index on T using
F(c1). It appears that if you execute "create or replace function F" and
provide a different implementation that the index still contains the results
from the original implementation, thus if you execute something like "selec
On Mon, 2007-10-22 at 08:20 -0400, Bill Moran wrote:
> In response to "Joshua D. Drake" <[EMAIL PROTECTED]>:
>
> > Ow Mun Heng wrote:
> > > I'm wondering if what I'm doing is redundant.
> > >
> > > I have a primary key on columns (A,B,C,D)
> > > and I've also defined an index based on the same c
In response to "Joshua D. Drake" <[EMAIL PROTECTED]>:
> Ow Mun Heng wrote:
> > I'm wondering if what I'm doing is redundant.
> >
> > I have a primary key on columns (A,B,C,D)
> > and I've also defined an index based on the same columns (A,B,C,D)
> >
> > and sometimes in the query explain, I see
Ow Mun Heng <[EMAIL PROTECTED]> writes:
> I'm wondering if what I'm doing is redundant.
> I have a primary key on columns (A,B,C,D)
> and I've also defined an index based on the same columns (A,B,C,D)
Yup, 100% redundant.
regards, tom lane
---(end
On Sun, 2007-10-21 at 20:49 -0700, Joshua D. Drake wrote:
> Ow Mun Heng wrote:
> > I'm wondering if what I'm doing is redundant.
> >
> > I have a primary key on columns (A,B,C,D)
> > and I've also defined an index based on the same columns (A,B,C,D)
> >
> > and sometimes in the query explain, I
Ow Mun Heng wrote:
I'm wondering if what I'm doing is redundant.
I have a primary key on columns (A,B,C,D)
and I've also defined an index based on the same columns (A,B,C,D)
and sometimes in the query explain, I see the pkey being used for the
scan instead of the index.
So.. That made me think
I'm wondering if what I'm doing is redundant.
I have a primary key on columns (A,B,C,D)
and I've also defined an index based on the same columns (A,B,C,D)
and sometimes in the query explain, I see the pkey being used for the
scan instead of the index.
So.. That made me think perhaps the addition
I was reading an interview with Chris Date the other day, which got me
thinking about a problem I'm currently having:
I have an application that keeps information in 6 denormalized tables,
D1 through D6. To tie things together, all these tables have a common
column, let's call it obj_id.
There
On 2/18/07, Chris <[EMAIL PROTECTED]> wrote:
Toby Tremayne wrote:
> Hi all,
>
> I'm just experimenting with tsearch2 - I have it all working fine but I
> was wondering if there's a way to create indexes containing vector
> columns from multiple tables? Or if not, how do people usually manage
> t
Toby Tremayne wrote:
Hi all,
I'm just experimenting with tsearch2 - I have it all working fine but I
was wondering if there's a way to create indexes containing vector
columns from multiple tables? Or if not, how do people usually manage
this kind of issue?
Postgres doesn't support multi-t
Hi all,
I'm just experimenting with tsearch2 - I have it all working fine
but I was wondering if there's a way to create indexes containing
vector columns from multiple tables? Or if not, how do people
usually manage this kind of issue?
Toby
---
I have tried testing the perofmance on indexing array element using standard
btree and it doesn't help anything. It still costing alot.
create index idx_properties_address_4 on properties ((address_arr[4]))
does contrib/intarray effective for text array?
On 3/16/06, Oleg Bartunov wrote:
co
Keary Suska wrote:
Thanks to Erik, Jeff, & Richard for their help.
I have a further inheritance question: do child tables inherit the indexes
created on parent columns, or do they need to be specified separately for
each child table? I.e., created via CREATE INDEX.
I assume at least that the im
Erik Jones <[EMAIL PROTECTED]> writes:
> No. In addition, child tables do not inherit primary keys. Think of it
> like this: if you did a \d to describe a table that you were going to
> use as a parent table in an inheritance chain, the child table would get
> everything in the table listing t
Keary Suska wrote:
Thanks to Erik, Jeff, & Richard for their help.
I have a further inheritance question: do child tables inherit the indexes
created on parent columns, or do they need to be specified separately for
each child table? I.e., created via CREATE INDEX.
I assume at least that the im
Thanks to Erik, Jeff, & Richard for their help.
I have a further inheritance question: do child tables inherit the indexes
created on parent columns, or do they need to be specified separately for
each child table? I.e., created via CREATE INDEX.
I assume at least that the implicit index created
1 - 100 of 210 matches
Mail list logo
