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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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&#
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
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
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
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.
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
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
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
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
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
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
> 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 :-(
;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
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
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@
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
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
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
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
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
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.
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
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
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
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
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
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 (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
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
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
--
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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
Adrian Klaver writes:
> On 01/08/2016 01:26 PM, Tom Lane wrote:
>> No, it's just a bug. Although apparently not many people do that, or
>> we'd have heard complaints before.
> That dredged up a memory from way back:
> http://www.postgresql.org/message-id/2004112
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 04:03:51PM -0500, Tom Lane wrote:
>> BTW, the one-liner fix that I'd had in mind when I wrote that does indeed
>> fix this particular problem, but after studying the code I realized that
>> there's a whole bunch of r
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 12:38:47PM -0500, Tom Lane wrote:
>> After digging through this, I figured out the problem: you'd installed
>> pg_trgm into the pg_catalog schema, whereas when I was testing I'd just
>> dropped it into the public
ou can make the modified_by column be a foreign
key referencing a table of users (it probably couldn't be defined
quite like "staff", but you get the idea). The presence of the foreign
key would be enough to cue pg_dump about load order.
regards, tom
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 11:23:21AM -0500, Tom Lane wrote:
>> A suggestion is to run the pg_upgrade with -r switch, which will leave a
>> litter of files in your working directory. Some of them will be named
>> like pg_upgrade_dump_NNN.custom and sh
p to dump things in an unexpected order, which
> could possibly explain the message we're seeing. But that's just a
> guess.
BTW, there will also be .log files, which might contain useful information
as well, especially if any of it is bleats from pg_dump about being unable
to b
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 11:12:09AM -0500, Tom Lane wrote:
>> Hm. I just tried running a pg_upgrade here on a 9.4 database containing
>> pg_trgm 1.1, and didn't see any particular problem, so there's some
>> additional factor needed to c
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 10:45:27AM -0500, Tom Lane wrote:
>> Just for completeness, can you tell us which pg_trgm version (1.0
>> or 1.1) is installed in the 9.4 database?
> Sure:
> (pg_trgm,1.1,"text similarity measurement and index sear
h internally uses a
> dump/restore cycle rather than calling pg_upgrade. That
> failed due to ordering problems with table data vs table
> constraints.)
That seems like an independent bug. Can you provide specifics?
regards, tom lane
--
Sent via pgsql-general
Ted Toth writes:
> This happens on simple INSERTs no RETURNING.
You're going to need to show a concrete example.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgr
stgresql.org/docs/devel/static/xoper-optimization.html
Again, that's something that could be improved in principle, but
the amount of work involved seems disproportionate to the likely
benefit.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general
answer, which might serve as long as your application only
cares about a small number of prefix lengths, is functional indexes.
If you create a functional index on "left(foo,3)" you're all set.
This won't scale well to a whole bunch of different lengths, though.
Steve Rogerson writes:
> On 05/01/16 19:47, Tom Lane wrote:
>> That's operating as designed. A unique constraint needs an index,
>> but not vice versa.
> I can see that might be plausible , hence the question but as a "unique index"
> imposes as constra
901 - 1000 of 14353 matches
Mail list logo
