Re: [BUGS] BUG #5707: Cross compilation for windows is broken
Has this been addressed? --- Alvaro Herrera wrote: > Excerpts from Robert Haas's message of vie oct 29 13:23:39 -0300 2010: > > On Tue, Oct 12, 2010 at 2:25 PM, Alvaro Herrera > > wrote: > > > Excerpts from Richard Evans's message of mar oct 12 12:48:45 -0300 2010: > > > > > >> When cross compiling for Windows using a separate build area, libpq.dll > > >> does > > >> not build because the .def file cannot be found. > > >> > > >> This appears to be caused by these lines in Makefile.shlib: > > > > > > Hmm, apparently this was made to work here: > > > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=26af72b4 > > > > > > and subsequently broken later: > > > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=234c7ce9 > > > > > > I think the real fix is to make the DEF files be generated in the > > > builddir, to complete the intention of the latter patch. > > > > Is anyone working on that? > > Not me. I tried, but mingw32-gcc doesn't work out of the box for me, > because configure is not testing for the right accept() arguments. > That's what I can do with the time I can dedicate to a problem like this > right now (i.e. not much). > > -- > ??lvaro Herrera > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5705: btree_gist: Index on inet changes query result
Teodor, would you please comment on this bug after reading the entire
thread which includes comments from other developers?
http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php
Thanks.
---
Andreas Karlsson wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5705
> Logged by: Andreas Karlsson
> Email address: andr...@proxel.se
> PostgreSQL version: 9.1
> Operating system: Linux
> Description:btree_gist: Index on inet changes query result
> Details:
>
> Hi,
>
> I was looking at the code to see how one would improve indexing of the inet
> types and saw an inconsistency between the compressed format
> (gbt_inet_compress) and how network_cmp_internal works. The btree_gist
> module ignores the netmask.
>
> This means that while the operator thinks 1.255.255.200/8 is smaller than
> 1.0.0.0 the GiST index thinks the opposite.
>
> An example for how to reproduce the bug:
>
> -- Demostrate that I did not get the operator wrong. :)
> SELECT '1.255.255.200/8'::inet < '1.0.0.0'::inet;
> ?column?
> --
> t
> (1 row)
>
> -- Create and populate table
> CREATE TABLE inet_test (a inet);
> INSERT INTO inet_test VALUES ('1.255.255.200/8');
>
>
> -- Without index
> SELECT * FROM inet_test WHERE a < '1.0.0.0'::inet;
> a
> -
> 1.255.255.200/8
> (1 row)
>
> EXPLAIN SELECT * FROM inet_test WHERE a < '1.0.0.0'::inet;
> QUERY PLAN
> -
> Seq Scan on inet_test (cost=0.00..26.38 rows=437 width=32)
>Filter: (a < '1.0.0.0'::inet)
> (2 rows)
>
> -- With index
> CREATE INDEX inet_test_idx ON inet_test USING gist (a);
> SET enable_seqscan = false;
>
> SELECT * FROM inet_test WHERE a < '1.0.0.0'::inet;
> a
> ---
> (0 rows)
>
> EXPLAIN SELECT * FROM inet_test WHERE a < '1.0.0.0'::inet;
>QUERY PLAN
>
>
> Index Scan using inet_test_idx on inet_test (cost=0.00..8.27 rows=1
> width=32)
>Index Cond: (a < '1.0.0.0'::inet)
> (2 rows)
>
> -- With btree index
> DROP INDEX inet_test_idx;
> CREATE INDEX inet_test_btree_idx ON inet_test USING btree (a);
> SELECT * FROM inet_test WHERE a < '1.0.0.0'::inet;
> a
> -
> 1.255.255.200/8
> (1 row)
>
> EXPLAIN SELECT * FROM inet_test WHERE a < '1.0.0.0'::inet;
>QUERY PLAN
>
>
>
> Index Scan using inet_test_btree_idx on inet_test (cost=0.00..8.27 rows=1
> width=32)
>Index Cond: (a < '1.0.0.0'::inet)
> (2 rows)
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] LOCALTIMESTAMP has wrong time zone
Solved. Changing the field datatype from TIMESTAMP to TIMESTAMPTZ fixed it. Now I can use now() as the default value. Strange that it just cropped up recently, but you're right we should be including time zone with that timestamp anyways. My deep gratitude for your time and help! JB -Original Message- From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov] Sent: Friday, February 25, 2011 11:15 AM To: j...@blackskytech.com; pgsql-bugs@postgresql.org; 'Tom Lane' Subject: RE: [BUGS] LOCALTIMESTAMP has wrong time zone "Jonathan Brinkman" wrote: > ## I COULDN'T MAKE IT BREAK USING PSQL. That's pretty solid evidence that the problem isn't in the PostgreSQL server. > This didn't always happen, it just started happening on various of > my tables a maybe couple weeks or so ago. I think it is related to > an update, either to Ubuntu 10.04 or Postgresql 8.4. I usually > apt-get update/upgrade whenever I see that updates are available. I would look at /var/log/dpkg.log to see what you installed at the point when things broke. > Also, this only occurs on my production server (Rackspace cloud). > My dev postgres server doesn't do this timestamp time-zone problem > at all. I would be taking a close look at what the differences are. Anything that is the same on both servers can't be the problem, right? I'm going to harp on one other point -- you will almost certainly be better off if you make these columns TIMESTAMP WITH TIME ZONE. This is the type which is meant to represent moments in the stream of time. It will behave as you probably expect in many more circumstances, especially when recording when events occurred. WITHOUT TIME ZONE is mostly useful for scheduling future events which you want to happen at different points in time in different time zones, or for scheduling things which should occur in whatever time is in effect locally when the related date arrives. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Corrupted index on 9.0.3 streaming hot standby
Hi, Do you still have the WAL files? what do you mean exactly? We don't have full history of WAL files from creation of hot streaming standby. They are recycled. We have set of WAL files from the point we discovered the corrupted index and stopped the cluster. But it was probably days after the index was corrupted... Kuba -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Function trunc() behaves in unexpected manner with different data types
On Fri, Feb 25, 2011 at 9:48 AM, Merlin Moncure wrote: > On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera > wrote: >> Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011: >> >>> no I wouldn't, and the pg_dump extra_float_digits setting addresses my >>> primary concern. The client has a similar issue though -- suppose it >>> fetches a value from the server and updates it back -- which record >>> gets the update? You would get different results if the client was >>> using binary or text features of the protocol. Not saying this is >>> wrong or needs to be fixed, just pointing it out :-). >>> >>> update foo set val=val + 1 where val = 2183.68; >> >> I think the mere idea of using floating point equality on a >> WHERE clause is bogus, regardless of text or binary format. > > That's a bridge to[sic] far -- akin to saying floating point should not > support equality operator. select count(*) from foo where val >= > 2183.68? you are ok getting different answers depending on method of > transmission of 2183.68 to the server? I stand corrected -- I did some digging and Postgres's handling of this issue is afaict correct: you are supposed to round on presentation only, and equality matching on floating point in sql (just like in C) is capricious exercise at best, at least without some defenses. So, we can definitely file under 'not a bug'. merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] LOCALTIMESTAMP has wrong time zone
"Jonathan Brinkman" wrote: > ## I COULDN'T MAKE IT BREAK USING PSQL. That's pretty solid evidence that the problem isn't in the PostgreSQL server. > This didn't always happen, it just started happening on various of > my tables a maybe couple weeks or so ago. I think it is related to > an update, either to Ubuntu 10.04 or Postgresql 8.4. I usually > apt-get update/upgrade whenever I see that updates are available. I would look at /var/log/dpkg.log to see what you installed at the point when things broke. > Also, this only occurs on my production server (Rackspace cloud). > My dev postgres server doesn't do this timestamp time-zone problem > at all. I would be taking a close look at what the differences are. Anything that is the same on both servers can't be the problem, right? I'm going to harp on one other point -- you will almost certainly be better off if you make these columns TIMESTAMP WITH TIME ZONE. This is the type which is meant to represent moments in the stream of time. It will behave as you probably expect in many more circumstances, especially when recording when events occurred. WITHOUT TIME ZONE is mostly useful for scheduling future events which you want to happen at different points in time in different time zones, or for scheduling things which should occur in whatever time is in effect locally when the related date arrives. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5899: Memory corruption when running psql
Excerpts from Ross Barrett's message of jue feb 24 13:36:34 -0300 2011: > > The following bug has been logged online: > > Bug reference: 5899 > Logged by: Ross Barrett > Email address: ross_barr...@rapid7.com > PostgreSQL version: 9.0.3 > Operating system: Ubuntu 9.10 > Description:Memory corruption when running psql > Details: > > Attempting to run psql complains that termcap db is not present (bug 5807). > Applying the work around of placing an /etc/termcap file from a Red Hat > system allowed psql to run 1x. Subsequent runs always yield a memory > error: Try LD_PRELOAD'ing libreadline -- or recompile psql linked to that instead of libedit. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Corrupted index on 9.0.3 streaming hot standby
Excerpts from Jakub Ouhrabka's message of vie feb 25 08:20:33 -0300 2011: > For details about corrupted index see below. The table and index in > question are mostly read-only (several queries per second) writes happen > only few times a day. > > We've backed up whole cluster and recreated it. > > Shall we investigate it further? How? Is it possible that we make some > mistake when doing initial backup which caused corruption? Is there a > way to check other indexes? Do you still have the WAL files? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Function trunc() behaves in unexpected manner with different data types
On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera wrote: > Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011: > >> no I wouldn't, and the pg_dump extra_float_digits setting addresses my >> primary concern. The client has a similar issue though -- suppose it >> fetches a value from the server and updates it back -- which record >> gets the update? You would get different results if the client was >> using binary or text features of the protocol. Not saying this is >> wrong or needs to be fixed, just pointing it out :-). >> >> update foo set val=val + 1 where val = 2183.68; > > I think the mere idea of using floating point equality on a > WHERE clause is bogus, regardless of text or binary format. That's a bridge to far -- akin to saying floating point should not support equality operator. select count(*) from foo where val >= 2183.68? you are ok getting different answers depending on method of transmission of 2183.68 to the server? merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Function trunc() behaves in unexpected manner with different data types
Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011: > no I wouldn't, and the pg_dump extra_float_digits setting addresses my > primary concern. The client has a similar issue though -- suppose it > fetches a value from the server and updates it back -- which record > gets the update? You would get different results if the client was > using binary or text features of the protocol. Not saying this is > wrong or needs to be fixed, just pointing it out :-). > > update foo set val=val + 1 where val = 2183.68; I think the mere idea of using floating point equality on a WHERE clause is bogus, regardless of text or binary format. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5900: Coredump on executing query
"Sergey Aleynikov" writes: > PostgreSQL version: 8.4.1 > Yesterday i've got a non-repeatable database server crash with following > messages in server log: > [ crash is within auto_explain according to backtrace ] I think most likely you got bit by this known bug: commit 85a646aee39b97b68bd70956db95afd11cde93a8 Author: Tom Lane Date: Thu Feb 18 03:06:53 2010 + Force READY portals into FAILED state when a transaction or subtransaction is aborted, if they were created within the failed xact. This prevents ExecutorEnd from being run on them, which is a good idea because they may contain references to tables or other objects that no longer exist. In particular this is hazardous when auto_explain is active, but it's really rather surprising that nobody has seen an issue with this before. I'm back-patching this to 8.4, since that's the first version that contains auto_explain or an ExecutorEnd hook, but I wonder whether we shouldn't back-patch further. IOW, if the query was aborted, it's unsafe to run auto_explain on it but the system sometimes tried anyway. Please update to 8.4.3 or later. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Function trunc() behaves in unexpected manner with different data types
On Fri, Feb 25, 2011 at 9:21 AM, Tom Lane wrote: > Merlin Moncure writes: >> right -- in understand how floating point works -- but are you are >> saying that you are ok with the fact that (for example) a table with a >> floating point unique key could dump and not restore? more >> specifically, a binary dump would restore but a text dump would not. > > pg_dump takes measures against that (see extra_float_digits). > >> I think this is a problem with our implementation -- not all versions >> of 2183.68 as outputted from the server are the same internally. > > It's an inherent property of float math. Yes, we could set the default > value of extra_float_digits high enough that distinct internal values > always had distinct text representations, but trust me, you would not > like it. no I wouldn't, and the pg_dump extra_float_digits setting addresses my primary concern. The client has a similar issue though -- suppose it fetches a value from the server and updates it back -- which record gets the update? You would get different results if the client was using binary or text features of the protocol. Not saying this is wrong or needs to be fixed, just pointing it out :-). update foo set val=val + 1 where val = 2183.68; merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Function trunc() behaves in unexpected manner with different data types
Merlin Moncure writes: > right -- in understand how floating point works -- but are you are > saying that you are ok with the fact that (for example) a table with a > floating point unique key could dump and not restore? more > specifically, a binary dump would restore but a text dump would not. pg_dump takes measures against that (see extra_float_digits). > I think this is a problem with our implementation -- not all versions > of 2183.68 as outputted from the server are the same internally. It's an inherent property of float math. Yes, we could set the default value of extra_float_digits high enough that distinct internal values always had distinct text representations, but trust me, you would not like it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Function trunc() behaves in unexpected manner with different data types
On Thu, Feb 24, 2011 at 8:03 PM, Greg Stark wrote: > On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure wrote: >> the root issue I think here is that the string version of the double >> precision math is approximated: > > No, it's simpler than that, all double precision math is approximated. > The root issue is that 2183.67 is not representable in a floating > point binary number. Just like 1/3 isn't representable in base 10 > (decimal) numbers many fractions aren't representable in base 2 > (binary) numbers. The result are repeated decimals like 0.... if you > multiply that by three you get 0.9 and if you truncate that you > get 0 insted of 1. > > It's the trunc() that's exposing the imprecision because like "=" it > depends on the precise value of the number down to the last digit. > Though depending on the arithmetic you can always make the precision > expand beyond the last digit anyways -- when you multiply by 100 you > magnify that imprecision too. right -- in understand how floating point works -- but are you are saying that you are ok with the fact that (for example) a table with a floating point unique key could dump and not restore? more specifically, a binary dump would restore but a text dump would not. I think this is a problem with our implementation -- not all versions of 2183.68 as outputted from the server are the same internally. put another way, text output from the server should unambiguously match what sourced the text. in the case of floating point, it does not...there are N versions of internal data that can match particular text output. I am speculating that the rounding is happening in the wrong place maybe. merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5900: Coredump on executing query
The following bug has been logged online:
Bug reference: 5900
Logged by: Sergey Aleynikov
Email address: sergey.aleyni...@gmail.com
PostgreSQL version: 8.4.1
Operating system: FreeBSD 7.3-STABLE amd64
Description:Coredump on executing query
Details:
I've a setup with 'auto_explain' enabled:
shared_preload_libraries = 'auto_explain'
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = '3s'
auto_explain.log_nested_statements = true
Yesterday i've got a non-repeatable database server crash with following
messages in server log:
Feb 24 17:44:25 sigeon postgres[91789]: [5-28]
-> Index Scan using ind_log_1573_reversed on logs_1573 logs
(cost=0.00..
Feb 24 17:44:25 sigeon postgres[91789]: [5-29]
Index Cond: (opcode = 2302)
Feb 24 17:44:25 sigeon postgres[91789]: [5-30]->
Index Scan using "ind_users_modiifers_u+mod" on users_modifiers
(cost=0.00..4.15
Feb 24 17:44:25 sigeon postgres[91789]: [5-31]
Index Cond: ((users_modifiers.uid = public.logs.uid) AND
(users_modifiers.modifi
Feb 24 17:44:25 sigeon postgres[91789]: [5-32] ->
Index Scan using pkey_usersinfo on users_info (cost=0.00..4.20 rows=1
width=42)
Feb 24 17:44:25 sigeon postgres[91789]: [5-33]
Index Cond: (users_info.uid = users_modifiers.uid)
Feb 24 17:44:25 sigeon postgres[91789]: [5-34]
Filter: ((users_info.regdate >= $1) AND (users_info.regdate < $2))
Feb 24 17:44:25 sigeon postgres[91789]: [5-35] CONTEXT: PL/pgSQL function
"get_register_leveled_stats" line 3 at RETURN QUERY
Feb 24 17:44:25 sigeon postgres[91789]: [5-36] STATEMENT: SELECT * FROM
get_register_leveled_stats('02/24/11 00:00:00','02/25/11 00:00:00');
Feb 24 17:44:28 sigeon postgres[1166]: [5-1] LOG: server process (PID
91789) was terminated by signal 11: Segmentation fault
Feb 24 17:44:28 sigeon postgres[1166]: [6-1] LOG: terminating any other
active server processes
Feb 24 17:44:28 sigeon postgres[92550]: [7-1] FATAL: the database system is
in recovery mode
Feb 24 17:44:28 sigeon postgres[1166]: [7-1] LOG: archiver process (PID
1171) exited with exit code 1
Backtrace is:
(gdb) bt
#0 0x0060bf79 in quote_identifier ()
#1 0x004ed45c in explain_outNode ()
#2 0x004ee253 in ExplainPrintPlan ()
#3 0x00080120112a in explain_ExecutorEnd () from
/usr/local/pgsql/lib/auto_explain.so
#4 0x004fa3cf in PortalCleanup ()
#5 0x0067389a in PortalDrop ()
#6 0x005bf2e9 in exec_simple_query ()
#7 0x005bffd7 in PostgresMain ()
#8 0x00599287 in ServerLoop ()
#9 0x00599f7e in PostmasterMain ()
#10 0x0054ce64 in main ()
Since this is non-repeatable crash (this is common statistical query, run
tens times a day), i can't make a debug build of PG to show more info.
Executed query (get_register_leveled_stats) was following:
CREATE OR REPLACE FUNCTION get_register_leveled_stats(_from timestamp
without time zone, _to timestamp without time zone) RETURNS setof
f_grls_result AS
$BODY$
begin
return query
select z.*, z.a + z.b + z.c + z.d + z.e from (
select sum(other)::integer as a, sum(vk)::integer as b,
sum(vk_ref)::integer as c, sum(mailru)::integer as d, sum(od)::integer as e,
value::integer
from (
select uid,
case when eid is null and mlid is null
then 1 else 0 end as other,
case when eid is not null and net = 0
and referral is null then 1 else
0 end as vk,
case when eid is not null and net = 0
and referral is not null then 1
else 0 end as vk_ref,
case when eid is not null and net = 12
then 1 else 0 end as od,
case when mlid is not null then 1 else
0 end as mailru
from users_info
where regdate >= _from and regdate < _to
) z
inner join users_modifiers on (users_modifiers.uid =
z.uid)
where modifiyer = 808
and origin = 239
group by value
order by value asc
) z
;
end
$BODY$
LANGUAGE 'plpgsql' stable;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Corrupted index on 9.0.3 streaming hot standby
Hi, we've found that we have corrupted index on 9.0.3 streaming hot standby. Master works ok. There is one more non-streaming standby which is ok as well. Platform is 64bit Linux. Database cluster and this database were created on 9.0.2 and than upgraded to 9.0.3. We are not aware of any crash on either master or streaming standby but we didn't investigate it deeply yet. For details about corrupted index see below. The table and index in question are mostly read-only (several queries per second) writes happen only few times a day. We've backed up whole cluster and recreated it. Shall we investigate it further? How? Is it possible that we make some mistake when doing initial backup which caused corruption? Is there a way to check other indexes? Thanks, Kuba set enable_bitmapscan to on ; explain analyze select * from tXX where colXX = '18'; QUERY PLAN Bitmap Heap Scan on tXX (cost=4.49..96.56 rows=30 width=102) (actual time=0.018..0.018 rows=0 loops=1) Recheck Cond: (colXX = '18'::text) -> Bitmap Index Scan on tXX_colXX_idx (cost=0.00..4.48 rows=30 width=0) (actual time=0.015..0.015 rows=0 loops=1) Index Cond: (colXX = '18'::text) Total runtime: 0.053 ms set enable_bitmapscan to off ; explain analyze select * from tXX where colXX = '18'; QUERY PLAN --- Seq Scan on tXX (cost=0.00..736.65 rows=30 width=102) (actual time=1.579..8.727 rows=30 loops=1) Filter: (colXX = '18'::text) Total runtime: 8.766 ms -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
