a kluge but ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ork in general for arbitrary settings.) Role "inheritance"
applies to granted privileges only.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
te the command:
> alter table pg_largeobject set tablespace some_tablespace;
Why do you think you need single-user mode for that?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.pos
Andreas Joseph Krogh writes:
> På søndag 10. januar 2016 kl. 16:40:23, skrev Tom Lane <mailto:t...@sss.pgh.pa.us>>:
> Andreas Joseph Krogh writes:
>>> Then I have to execute the command:
>>> alter table pg_largeobject set tablespace some_tablespace;
> W
st still have at least one database that contains references
to python2 (check pg_language to be sure).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ow it at each iteration if the
> title is set.
Perhaps we should replace the "Watch every Ns" text by the user-given
title if a title has been set? That would conserve screen space.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsq
"David G. Johnston" writes:
> On Mon, Jan 11, 2016 at 8:14 AM, Tom Lane wrote:
>> Perhaps we should replace the "Watch every Ns" text by the user-given
>> title if a title has been set? That would conserve screen space.
> âThe extra line doesn't bo
here:
http://www.postgresql.org/message-id/9072.966741...@sss.pgh.pa.us
and the surrounding thread is well worth reading as well. Doesn't
really seem like the discussion has moved much since 2000 :-(
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-g
ready be covered under other sections of the CoC no?
Another possibly offensive aspect of the example you're describing
is someone trying to pass themselves off as a major contributor when
they're not. But I hesitate to try to draw guidelines for that either.
re
associated enforcement mechanism) to be designed to
discourage this sort of let's-begin-with-public-attacks approach to
problem resolution. How we get to that exactly, I don't know.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
see Regina Obe's posts.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ally unreasonable to see him as representing the project
in those statements.
(Note: I have not verified the facts of the matter, but this is what
was alleged in the thread.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
Kevin Grittner writes:
> On Mon, Jan 11, 2016 at 4:10 PM, Tom Lane wrote:
>> I thought we were already at that point; see Regina Obe's posts.
> Oh, are you referring to this:?
> http://www.postgresql.org/message-id/001201d14c96$fc26ed70$f474c850$@pcorp.us
> For some re
personal attacks.
That's not really meeting in the middle: it still specifies exactly
one set of disapproved topics. Might be OK if it read like
"... personal comments, for example ones related to gender, ..."
regards, tom lane
--
Sent via pgsql-general ma
Paul Jones writes:
> On Mon, Jan 11, 2016 at 10:04:16AM -0500, Tom Lane wrote:
>> It looks like pg_upgrade tries to load all libraries from functions in
>> any database in the old cluster into a single session in the new cluster,
>> which will fail in a scenario like this eve
Hi,
Congrats on the official release of 9.5
And I'd like bring up the issue again about if 9.6 would address the jsonb
performance issue
with large number of top level keys.
It is true that it does not have to use JSON format. it is about
serialization and fast retrieval
of dynamic tree structure
wn member of a community. When you are, well, your
public persona is partly intertwined with that community, and you can't
just turn that connection on and off.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ith %rowtype.
I think you could just use RECORD instead ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
pg_upgrade has no ability to do that for you though, which would
make it an error-prone manual process. Also, it'd be far from
zero-downtime since you still gotta rebuild a lot of indexes.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nd if you are looking at a seriously painful dump+reload
it'd be worth the trouble to debug a process for it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Andreas Joseph Krogh writes:
> What about ORDER BY on columns without an index, would they sort correctly?
Sorting is sorting, it'll just use whatever collation is specified or
implied.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql
, one thing at a time...)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e with Kevin that his version looks a lot more like a real
CoC. His is surely still amenable to some editing, but there are also
things in your version that we can do without. Particularly the "not
about being offended" line. That's pretty defensive and unwelcoming,
IMO, and that i
en when X,Y, and Z are perfectly neutral technical points. "Of any
kind" doesn't improve that either. I'm on board with the "personal
attacks" part. Maybe "disparaging personal remarks" would be better?
regards, tom lane
--
Sent v
David Grelaud writes:
> Statistics are not propagated when Common Table Expressions (CTE) are used.
> The cardinality of a CTE is equal to 1 most of the time
Really?
The rest of this seems to be proceeding from completely false assumptions.
regards, tom lane
--
est of this is that it's got the right
idea, but it could be cut to about half the length and be better
off for that. Short and sweet is the way, IMO.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
K (not_null_in_parent IS NOT NULL) NO INHERIT.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
in the CoC per se. If we start trying to write that
sort of rule, the CoC will be multiple pages long and no one will read it.
(I thought Kevin's last draft was already too long.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
k) 9.4. Before
that the "if exists" semantics only applied to the trigger itself,
not to the relation.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
outer rel*. This test isn't doing that; it will
happily accept inner rels that are parameterized by some unrelated rel.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
before 6.
I might be wrong, but I think two passes of regexp_replace would
do what you want in this example.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
installed in
standard installations.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ing styles.
Well, it's the way the SQL committee specified collations to work, so
we're pretty much stuck with that syntax.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
o more than one
Visual Studio release.
Hopefully, if they removed the visible declaration intentionally, they
provided some other way to get at those locale names. That's what we
need to be looking for, not hoping that direct access to undocumented
structures will continue to work.
needed only because
the OP used E'...' syntax for his string literal. In a plain SQL
string literal, backslash isn't special.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hello:
I have a big table with that is always appended with new data with a unique
sequence id (always incremented, or timestamp as unique index) each row.
I'd like to sample, say 100 rows out of say 1000 rows evently across all
the rows,
so that it would return rows of1, 101, 201, 301you g
Mon, Jan 25, 2016 at 3:48 AM, Vik Fearing wrote:
> On 01/25/2016 05:09 AM, Tom Smith wrote:
> > Hello:
> >
> > I have a big table with that is always appended with new data with a
> unique
> > sequence id (always incremented, or timestamp as unique index) each ro
Yeah. I am looking for fastest possible method that Postgresql would
use its internal data structure knowledge to walk through the timestamp
index
and resturns every "nth" row
On Mon, Jan 25, 2016 at 5:56 AM, Simon Riggs wrote:
> On 25 January 2016 at 09:44, Matija Lesar wrote:
>
>
>> you can a
o have to deal w/ per client index building and
> maintenance. So is there a rule of thumb design wise for variable
> selectivity as I've described?
See
http://www.postgresql.org/docs/9.4/static/indexes.html
particularly sections 11.3 and 11.5.
regards, tom lane
-
ce to make it clear that PRIMARY KEY is
equivalent to UNIQUE+NOTNULL in terms of the data constraint that it
enforces, without implying that there is no other difference. I'm not
sure about a short and clear expression of that though ...
regards, tom lane
--
Sent via
Postgres
mail archives go back nearly twenty years at this point, and we have
every expectation of still being around in another ten or twenty.
Very few outside URLs are likely to survive that long.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql
don't find
{ FOO | BAR } especially hard to read, but { FOO } is confusing because
you expect the {}'s to mean something and they really do not.
I'd be inclined to reduce this to
REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } name
We can put back the extra decora
EINVAL as meaning we should retry with a different key, because if
the problem is indeed the SEMMSL limit, we'd be in an infinite loop.
You can probably get past this for the moment if you can remove the
semaphore set with key 2, but I'd advise filing a FreeBSD kernel
bug about their choi
phore set already exists", but then on
key 2 we got EINVAL instead. That makes this even more curious. I'd
be interested to see what "ipcs -s" says, if you have that command.
(You might need to run it as root to be sure it will show all sempaphores.)
reg
477e84fe2471cb675234fce75cd6bb4bc2cf481
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
at the cost of making
deletions from countries much slower. Since there are cases where
that's a reasonable tradeoff, we don't prohibit you from omitting
the index ... but it is a pretty standard foot-gun.
regards, tom lane
--
Sent via pgsql-general maili
iteral to get assigned a definite type.
There's been occasional discussion of changing that behavior, but it's
not real clear that it wouldn't create as many problems as it solves.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
f you're up for nuking the entire existing foreign-key
infrastructure and starting over, you could think about doing things
some other way. But you're not going to get to anyplace other than
"run a query for each deleted row" without a *lot* of work.
rega
ing the matter with the larger community. For now, let's
try not to annoy the pgsql-general readership ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Using JSON/JSONB type in postgresql is usually due to the use case that the
keys (top level included) can not be predefined. this is the major
difference between NoSQL/Document and RDBMS.
Why would TOAST have to be used? Can some speciailly structured "raw"
files be used
outside current databa
27; FROM gwtest WHERE id=4), 'No') AS valid;
There's no null visible anywhere in that. I suppose that if there's
no row with id=4, there would be a null at runtime, but that's not
going to make any difference for parse-time determination of what
type the COALESCE() will ret
id attached to the "begin" statement, since at that point we have
started a new transaction but not assigned it any xid.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
is is normal behavior for linux.
Really? That sure seems misleading as can be, and not something we'd
want to be part of a new user's very first impression of Postgres.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@
Yury Zhuravlev writes:
> Tom Lane wrote:
>> Really? That sure seems misleading as can be, and not something we'd
>> want to be part of a new user's very first impression of Postgres.
> In configure we have similar messages:
> checking for int8... no
> check
;s POV, because it's hard to figure out what WAL record
> corresponds to the change you care about ...
To what extent does the commit_ts infrastructure fix this?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
> One of the databases was 34G when dumped by the 9.4 server is now dumped
> at 1.1G in the new 9.5 version (using pg_dump -Fc in both cases). What
> has caused such remarkable improvement?!
That seems really fishy. Better check to see if all your data
is still there :-(
cmake can't provide an equivalent
feature, that would be a large minus, because if you have a decent number
of cores -j makes a huge difference in build time.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ey at shaysler...@gmail.com or the Core Team at
pgsql-c...@postgresql.org.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ight have
to give it a hint about DMY vs. MDY field ordering via the DateStyle
setting. If your input is YMD order then you don't have to worry about
that at all.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
transaction active when the second table scan starts
can block concurrent index creation until it completes"; I think we need
to be a little clearer about when that happens or doesn't happen.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-gene
ngs
less confusing by having CREATE INDEX CONCURRENTLY not complete until
the index is fully usable. However, it appears the reason we don't do
that is it would create a risk of two CREATE INDEX CONCURRENTLY commands
deadlocking, ie they'd each think they have to wait for the other o
tatistic data that you're worried about.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
olds a DSM control header, nothing more. If you were actually doing
anything with dynamic shared memory, you'd see more such files.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.
differences could be harmless, but it could also mean that replaying
a WAL sequence against the database will result in inconsistencies.
If you're lucky this technique will work, but it's not reliable and not
supported. You really need to take an initial base backup after running
i
Hi:
I feel it is a stupid question.
Can BRIN index enforce uniqueness?
My issue is
the column I'd like to apply BRIN index also needs to be unique
(think of timestamp as primary key).
Thanks
dex with an identical one. (The pre-existing index should've been
enough to ensure HOT chain consistency for its columns.)
Perhaps you were doing something "cute" like replacing a single-column
index with a multi-column one?
regards, tom lane
--
Sent via
unique
On Thu, Feb 18, 2016 at 2:14 AM, David Rowley
wrote:
>
> On 18/02/2016 9:34 am, "Tom Smith" wrote:
> >
> > Hi:
> >
> > I feel it is a stupid question.
> >
> > Can BRIN index enforce uniqueness?
> > My issue is
> > the column I&#
ch outer row, which makes me wonder if the BETWEEN couldn't be replaced
with some sort of equality. But that might take some rethinking of the
data.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ompact storage from a column-store
database.
There's ongoing investigation into extending Postgres to support
column-style storage for better support of applications like that;
but any such feature is probably several years away, and it will
not come without performance compromises of its own.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ve
condition to justify having an index on it. I'd seriously consider
dropping that index as another solution approach.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
arger index would in fact be better. You might be able to counter that
to some extent by reducing effective_cache_size, though possibly that
cure is worse than the disease.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make change
ed
the way you want.
See
http://www.postgresql.org/docs/9.5/static/typeconv-oper.html
for a more detailed explanation.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Given how remarkably quick the single-index scan is, I also wonder if
>> that index is fully cached while we had to read some of the other index
>> from kernel or SSD.
> Unfortunately, this doesn't act
Seamus Abshere writes:
> On Mon, Feb 22, 2016, at 02:14 PM, Tom Lane wrote:
>> IOW, almost certainly we *don't* realize that the query will involve
>> scanning through gigabytes of index pages. But btree indexes are much
>> simpler and easier to make that estimate for
Seamus Abshere writes:
> Is there any other way to differentiate the 2 index scans? FWIW, 10% of
> houses are phoneable, 0.2% are in the city. (Maybe I'm just supposed to
> drop the index like Tom said.)
Hm. 10% is above the threshold where I'd usually think that an ind
at I don't
think the planner worries about the bitmap becoming "lossy", which would
result in many more heap tuple checks than it's predicting. It might be
that we need to model that effect. I don't think it's at play in Seamus'
example, given the large work_mem he
ing the setting to start with. Raising it 20X might
cause other queries to change behavior undesirably.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
tead, what you want is something like
create view visible_foo as
select from foo where deleted is null;
plus INSTEAD OF triggers that redirect inserts/updates/deletes from
visible_foo to foo. This way is likely to perform better than a rule
and have less-surprising semantics in corner cases.
UM. If we had a READ ONLY
property, I do not think it would affect that logic at all; it would just
prevent future mods going forward. Which, as noted, you could already do
by revoking suitable privileges.
regards, tom lane
--
Sent via pgsql-general mailing list (pgs
anybody, least of all the users
who don't care and don't need the additional overhead.
Lastly, even if we had a DDL timestamp, it wouldn't tell you anything
about what that last change was. So I think logging/auditing DDL
operations is a far better path to pursue.
tinue to work as it does now.
I'm not sure if anything besides json[b]_populate_record needs to change
similarly, but we ought to look at all those conversion functions with
the thought of nested containers in mind.
regards, tom lane
PS: I'm not volunteering to do the work here, but it seems like a good
change to make.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nitely require some restructuring of the code
to make populate_record_worker (or some portion thereof) recursive, and
probably some entirely new code for array conversion; and making
json_populate_recordset behave similarly might take refactoring too.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
OP TABLE. I'm not impressed.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ould be bad in a different way than "much
lower", but still bad.)
I imagine this could be addressed by some rule about how if you don't
own the table then your default_statistics_target is overridden by
the global setting, but that would be a mess both conceptually and
imple
lier, I doubt anyone wants to invest the work.
So I'm just going to go improve the comment and error message and
leave it at that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
out ON SELECT?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ation
> 2016-03-02 14:58:09 EST [14366]: [11-1] HINT: Enable the "track_counts"
> option.
Or both changes, or something else entirely?
I'd be interested to hear how you perceived these log messages and
what you think might help the next person.
regards, tom
e CASCADE;
though you'll probably have to do that in every database of the
installation.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
riation in the way this stuff is
configured that any hint would be likely to just be misleading.
> This is getting a bit deep for a rare problem like this - I think that
> making âthe root messages WARNING (or ERROR)
ERROR would mean that the postmaster fails to start at all. That does
n what your dynamic linker does
about it.
What exactly does the crash look like --- anything interesting in the
postmaster log? (If your logging setup fails to capture postmaster
stderr, now would be a good time to fix that.) Have you tried to
get a back-trace with gdb?
regards,
haracters used in SQL operator names.
It would likely have been cleaner to just disallow operator names
ending in "+" or "-", but we had several long-established names that
failed to conform to that, so this was the best compromise we could
come up with between flexibility
heap_form_tuple
somewhere along the line.)
A general tip for getting C code to work is to turn on as many
compiler warnings as you can, and never ignore any of them.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes t
27;s
no such thing in the core PG distribution, but the only hard part of making
your own is figuring out what to name the operator ;-)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
how with
a lot less risk of side-effects elsewhere. But it's not exactly
trivial because of interactions with INSERT ... SELECT.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ll signature of PQexec(), nor of any of its
variants.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
at fails in stock community source
code, I'll be happy to take a look.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
it does happen, I'd be happy to look
into it, because I agree it'd be a bug. But I have other things to spend
my time on than reverse-engineering test cases out of code fragments
dependent on incompletely-described custom modifications of Postgres.
regards, tom l
shape. Something
along the lines of (untested)
select min((select min(sc_id) from legs where scdate = gs))
from generate_series(20160219, 20160221) gs
This would only work well for relatively small ranges of scdate,
but if you had a large range then I think the original plan
would've been fi
Geoff Winkless writes:
> On 7 March 2016 at 14:51, Tom Lane wrote:
>> Because the other way is estimated to be cheaper. The estimate is
>> wrong, because it's based on a statistical assumption that's wrong
>> (ie that sc_id and scdate are uncorrelated), but it&#x
scan. I suspect that
it's pricing the IOS very high because a lot of the table is dirty
and therefore will have to be visited even in a nominally index-only
scan. You might check whether the plan choice changes immediately
after a VACUUM of the table.
regards, tom lane
701 - 800 of 14353 matches
Mail list logo
