Re: [GENERAL] Simple Query not using Primary Key Index

Here is the dumb part 😱 Turns out what caused my confusion that I had an identical table in another schema and I used different sessions with a different search_path with different results. Thank you for helping me on this. On Mon, Feb 6, 2017, 7:03 PM Vitaly Burovoy wrote: > On 2/6/17, Aron P

Re: [GENERAL] Simple Query not using Primary Key Index

On 2/6/17, Aron Podrigal wrote: > In general, I do not understand why a PK index should not be used when the > query can be satisfied by the index itself. Can anyone give some reason to > this? > > On Mon, Feb 6, 2017, 6:29 PM Aron Podrigal > wrote: > >> EXPLAIN ANALYZE does not tell me much. It

Re: [GENERAL] Simple Query not using Primary Key Index

On Mon, Feb 6, 2017 at 4:16 PM, Podrigal, Aron wrote: > Hi, > > I noticed when I do a simple SELECT id FROM mytable WHERE id = > 'cb81d070-4213-465f-b32e-b8db43b83a25'::UUID Postgres does not use the > primary key index and opts for a Seq Scan. > > I of course did VACUUM ANALYZE and I have reset

Re: [GENERAL] Simple Query not using Primary Key Index

After resetting all statistics it still opts for a Seq Scan. I went ahead to test with creating another table and querying that, and it shows on that test table to be using the index. So I wonder if there is anything else that may effect the planner. is there a way I can dog into this and see the s

Re: [GENERAL] Simple Query not using Primary Key Index

On 2/6/17, Podrigal, Aron wrote: > Hi, > > I noticed when I do a simple SELECT id FROM mytable WHERE id = > 'cb81d070-4213-465f-b32e-b8db43b83a25'::UUID Postgres does not use the > primary key index and opts for a Seq Scan. > > I of course did VACUUM ANALYZE and I have reset statistics But no sig

Re: [GENERAL] Simple Query not using Primary Key Index

In general, I do not understand why a PK index should not be used when the query can be satisfied by the index itself. Can anyone give some reason to this? On Mon, Feb 6, 2017, 6:29 PM Aron Podrigal wrote: > EXPLAIN ANALYZE does not tell me much. It doesn't say why the planner opts > for not usi

Re: [GENERAL] Simple Query not using Primary Key Index

EXPLAIN ANALYZE does not tell me much. It doesn't say why the planner opts for not using the Primary key index. On Mon, Feb 6, 2017, 6:23 PM Alban Hertroys wrote: > > > On 7 Feb 2017, at 0:16, Podrigal, Aron wrote: > > > > Hi, > > > > I noticed when I do a simple SELECT id FROM mytable WHERE id

Re: [GENERAL] Simple Query not using Primary Key Index

> On 7 Feb 2017, at 0:16, Podrigal, Aron wrote: > > Hi, > > I noticed when I do a simple SELECT id FROM mytable WHERE id = > 'cb81d070-4213-465f-b32e-b8db43b83a25'::UUID Postgres does not use the > primary key index and opts for a Seq Scan. > > I of course did VACUUM ANALYZE and I have rese

[GENERAL] Simple Query not using Primary Key Index

Hi, I noticed when I do a simple SELECT id FROM mytable WHERE id = 'cb81d070-4213-465f-b32e-b8db43b83a25'::UUID Postgres does not use the primary key index and opts for a Seq Scan. I of course did VACUUM ANALYZE and I have reset statistics But no sign. Is there any particular thing I should be l

Re: [GENERAL] BST Time Zone Discrepancy

Thank you, Steve and Adrian, for clarifying. Igal Sapir Lucee Core Developer Lucee.org

Re: [GENERAL] BST Time Zone Discrepancy

On 02/06/2017 12:44 PM, Igal @ Lucee.org wrote: Tom, Thank you for your reply: On 2/6/2017 12:18 PM, Tom Lane wrote: This is controlled by the timezone_abbreviations file, which if you haven't changed it lists: # CONFLICT! BST is not unique # Other timezones: # - BST: Bougainville Standard T

Re: [GENERAL] BST Time Zone Discrepancy

On Mon, Feb 6, 2017 at 12:44 PM, Igal @ Lucee.org wrote: > Tom, > > Thank you for your reply: > On 2/6/2017 12:18 PM, Tom Lane wrote: > > This is controlled by the timezone_abbreviations file, which if > > you haven't changed it lists: > > # CONFLICT! BST is not unique > # Other timezones: > # -

Re: [GENERAL] BST Time Zone Discrepancy

Tom, Thank you for your reply: On 2/6/2017 12:18 PM, Tom Lane wrote: This is controlled by the timezone_abbreviations file, which if you haven't changed it lists: # CONFLICT! BST is not unique # Other timezones: # - BST: Bougainville Standard Time (Papua New Guinea) BST 3600 D # British

Re: [GENERAL] BST Time Zone Discrepancy

"Igal @ Lucee.org" writes: > I've been having some issues with using BST as a timezone, so I checked > the Postgres catalogs and found a discrepancy. > ... > But in pg_timezone_names I get an 11-hr offset with a completely > different time zone. > intranet=> SELECT * FROM pg_timezone_names WHER

[GENERAL] BST Time Zone Discrepancy

I've been having some issues with using BST as a timezone, so I checked the Postgres catalogs and found a discrepancy. I expected it to be British Summer Time, which is a Daylight Saving Time in England and has a 1-hour UTC offset. In pg_timezone_abbrevs I see a 1-hr offset and is_dst set to