> Or, better, persuade the app to label the value "
public.push_guid
" since that is the column's type...a type you haven't defined for us. If you get to add explicit casts this should be easy...but I'm not familiar with the framework you are using.
push_guid was a CHARACTER(36) colu
On Thu, Jun 16, 2016 at 11:05 AM, Tom Lane wrote:
> meike.talb...@women-at-work.org writes:
> > When I query this through pgsql, the queries are fast as expected.
> > select * from push_topic where guid =
> 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'
> > Index Scan using push_topic_idx_topicguid on pu
meike.talb...@women-at-work.org writes:
> When I query this through pgsql, the queries are fast as expected.
> select * from push_topic where guid = 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'
> Index Scan using push_topic_idx_topicguid on push_topic (cost=0.42..8.44
> rows=1 width=103) (actual time=0
gresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of
meike.talb...@women-at-work.org
Sent: Thursday, June 16, 2016 12:59 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Index not used
Hello,
I've a basic table with about 100K rows:
CREATE TABLE "public".&q
Hello,
I've a basic table with about 100K rows:
CREATE TABLE "public"."push_topic" (
"id" Serial PRIMARY KEY,
"guid" public.push_guid NOT NULL,
"authenticatorsending" Varchar(32) NOT NULL,
"authenticatorsubscription" Varchar(32) NOT NULL,
"countpushed" Integer NOT NULL,
"datecreated" ti
On Sun, 2 Apr 2006, Jan Kesten wrote:
> Stephan Szabo schrieb:
>
> > Did you reset the table contents between these two (remember that
> > explain analyze actually runs the query)? The second appears to be
> > changing no rows from the output.
>
> I for myself did not, but as there are runnig aut
Stephan Szabo schrieb:
> Did you reset the table contents between these two (remember that
> explain analyze actually runs the query)? The second appears to be
> changing no rows from the output.
I for myself did not, but as there are runnig automatic jobs
periodically I can't tell, if one ran i
On Fri, 31 Mar 2006, Jan Kesten wrote:
>
> Hi folks!
>
> I have just a issue again with unused indexes. I have a database with a
> couple of tables and I have to do an sync job with them. For marking
> which row has to be transfered I added a new column token (integer, I
> will need some more toke
Hi folks!
I have just a issue again with unused indexes. I have a database with a
couple of tables and I have to do an sync job with them. For marking
which row has to be transfered I added a new column token (integer, I
will need some more tokens in near future) to every table.
Before determini
Андрей Репко wrote:
Здравствуйте Richard,
Tuesday, September 27, 2005, 2:08:31 PM, Вы писали:
sart_ma=# EXPLAIN ANALYZE SELECT alias_id FROM ma_data GROUP BY alias_id;
QUERY PLAN
---
Андрей Репко wrote:
RH> What happens if you use something like
RH>SELECT DISTINCT alias_id FROM ma_data;
sart_ma=# EXPLAIN ANALYZE SELECT DISTINCT alias_id FROM ma_data;
QUERY PLAN
-
Здравствуйте Richard,
Tuesday, September 27, 2005, 2:08:31 PM, Вы писали:
>> sart_ma=# EXPLAIN ANALYZE SELECT alias_id FROM ma_data GROUP BY alias_id;
>>QUERY PLAN
>> -
Здравствуйте Richard,
Tuesday, September 27, 2005, 1:48:15 PM, Вы писали:
RH> Andrey Repko wrote:
>>
>> I have table ma_data, that contain above 30 rows.
>>This table has primary key id, and field alias_id.
>>I create index (btree)on this field.
>>Set statistic:
>>
>> ALTER
Andrey Repko wrote:
I have table ma_data, that contain above 30 rows.
This table has primary key id, and field alias_id.
I create index (btree)on this field.
Set statistic:
ALTER TABLE "public"."ma_data"
ALTER COLUMN "alias_id" SET STATISTICS 998;
So, when I do somethin
Hello all,
I have table ma_data, that contain above 30 rows.
This table has primary key id, and field alias_id.
I create index (btree)on this field.
Set statistic:
ALTER TABLE "public"."ma_data"
ALTER COLUMN "alias_id" SET STATISTICS 998;
So, when I do something like
On 11.09.2005, at 11:03 Uhr, Andreas Seltenreich wrote:
I'm not perfectly sure, but since the index could only be used with a
subset of all possible parameters (the pattern for like has to be
left-anchored), I could imagine the planner has to avoid the index in
order to produce an universal plan
Guido Neitzer schrob:
> I have a performance problem with prepared statements (JDBC prepared
> statement).
>
> This query:
>
> PreparedStatement st = conn.prepareStatement("SELECT id FROM
> dga_dienstleister WHERE plz like '45257'");
>
> does use an index.
>
> This query:
>
> String pl
Hi.
I have a performance problem with prepared statements (JDBC prepared
statement).
This query:
PreparedStatement st = conn.prepareStatement("SELECT id FROM
dga_dienstleister WHERE plz like '45257'");
does use an index.
This query:
String plz = "45257";
PreparedStateme
Josh Berkus wrote:
Sebastian,
I'm having another problem with a query that takes to long, because
the appropriate index is not used.
PostgreSQL is not currently able to push down join criteria into UNIONed
subselects. It's a TODO.
And the appends in a "SELECT * from parent" are UNIONs,
Sebastian,
> I'm having another problem with a query that takes to long, because
> the appropriate index is not used.
PostgreSQL is not currently able to push down join criteria into UNIONed
subselects. It's a TODO.
Also, if you're using inherited tables, it's unnecessary to use UNION; just
Hi all,
I'm having another problem with a query that takes to long, because
the appropriate index is not used.
I found some solutions to this problem, but I think Postgres should do
an index scan in all cases.
To show the problem I've attached a small script with a testcase.
Thanks in adva
On Thu, 21 Apr 2005, Enrico Weigelt wrote:
> I'm doing a simple lookup in a small table by an unique id, and I'm
> wondering, why explains tells me seqscan is used instead the key.
>
> The table looks like:
>
> idbigint primary key,
> a varchar,
> b varchar,
> c
If id is PK, the query shoudl return 1 row only...
--- Enrico Weigelt <[EMAIL PROTECTED]> wrote:
>
> Hi folks,
>
>
> I'm doing a simple lookup in a small table by an
> unique id, and I'm
> wondering, why explains tells me seqscan is used
> instead the key.
>
> The table looks like:
>
> id
On Thursday 21 April 2005 12:05, Enrico Weigelt wrote:
> Hi folks,
>
>
> I'm doing a simple lookup in a small table by an unique id, and I'm
> wondering, why explains tells me seqscan is used instead the key.
>
> The table looks like:
>
> idbigint primary key,
> a varchar,
Hi folks,
I'm doing a simple lookup in a small table by an unique id, and I'm
wondering, why explains tells me seqscan is used instead the key.
The table looks like:
id bigint primary key,
a varchar,
b varchar,
c varchar
and I'm quering: select * from foo w
I ran analyze; several times.
rgds
Antony Paul
On Mon, 07 Feb 2005 12:53:30 +0100, Jan Poslusny wrote:
> It depends on many circumstances, but, at first, simple question: Did
> you run vacuum analyze?
> I am satisfied with functional indexes - it works in my pg 7.4.x.
>
> Antony Paul wrote:
>
Sorry I forgot to mention it. I am using 7.3.3. I will try it in 8.0.0
rgds
Antony Paul
On Mon, 7 Feb 2005 12:46:05 +0100, Steinar H. Gunderson
<[EMAIL PROTECTED]> wrote:
> On Mon, Feb 07, 2005 at 04:44:07PM +0530, Antony Paul wrote:
> > On more investigation I found that index scan is not us
It depends on many circumstances, but, at first, simple question: Did
you run vacuum analyze?
I am satisfied with functional indexes - it works in my pg 7.4.x.
Antony Paul wrote:
On more investigation I found that index scan is not used if the query
have a function in it like lower() and an index
On Mon, Feb 07, 2005 at 04:44:07PM +0530, Antony Paul wrote:
> On more investigation I found that index scan is not used if the query
> have a function in it like lower() and an index exist for lower()
> column.
What version are you using? 8.0 had fixes for this situation.
/* Steinar */
--
Homep
On more investigation I found that index scan is not used if the query
have a function in it like lower() and an index exist for lower()
column.
rgds
Antony Paul
On Mon, 7 Feb 2005 14:37:15 +0530, Antony Paul <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am facing a strange problem when I run EXP
Hi all,
I am facing a strange problem when I run EXPLAIN against a table
having more than 10 records. The query have lot of OR conditions
and when parts of the query is removed it is using index. To analyse
it I created a table with a single column, inserted 10
records(random number) in
Mario Ivankovits <[EMAIL PROTECTED]> writes:
> After populating the table with 8920 records and "analyze" the scenario
> gets even worser:
> select * from tt where seckey = 1;
> Seq Scan on tt (cost=0.00..168.50 rows=1669 width=12) (actual
> time=0.000..15.000 rows=1784 loops=1)
> Filter: (se
Mario Ivankovits wrote:
Hello !
Sorry if this has been discussed before, it is just hard to find in the
archives using the words "or" or "in" :-o
I use postgres-8.0 beta4 for windows.
I broke down my problem to a very simple table - two columns
"primary_key" and "secondary_key". Creates and Inse
Hello !
Sorry if this has been discussed before, it is just hard to find in the
archives using the words "or" or "in" :-o
I use postgres-8.0 beta4 for windows.
I broke down my problem to a very simple table - two columns
"primary_key" and "secondary_key". Creates and Insert you will find below.
ake this query a little more faster. Suggestions?
Regards,
Andy.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Andrei Bintintan" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 19, 2004 7:52 PM
Subject: Re: [PERFORM] Ind
an" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 19, 2004 7:52 PM
Subject: Re: [PERFORM] Index not used in query. Why?
> "Andrei Bintintan" <[EMAIL PROTECTED]> writes:
> > Hi to all! I have the following query. The execution time is very
"Andrei Bintintan" <[EMAIL PROTECTED]> writes:
> Hi to all! I have the following query. The execution time is very big, it
> doesn't use the indexes and I don't understand why...
Indexes are not necessarily the best way to do a large join.
> If I use the following query the indexes are used:
The
Hi to all! I have the following query. The execution time is very big, it
doesn't use the indexes and I don't understand why...
SELECT count(o.id) FROM orders o
INNER JOIN report r ON o.id=r.id_order
INNER JOIN status s ON o
Maybe add an order by artist to force a groupaggregate ?
Hi all, a small question:
I've got this table "songs" and an index on column artist. Since
there's about
one distinct artist for every 10 rows, it would be nice if it could use
this
index when counting artists. It doesn't however:
Hi all, a small question:
I've got this table "songs" and an index on column artist. Since there's about
one distinct artist for every 10 rows, it would be nice if it could use this
index when counting artists. It doesn't however:
lyrics=> EXPLAIN ANALYZE SELECT count(DISTINCT artist) FROM song
40 matches
Mail list logo
